From: tu bo <tubo@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org,
"dahi@linux.vnet.ibm.com" <dahi@linux.vnet.ibm.com>,
jfrei@linux.vnet.ibm.com,
Michael Mueller <mimu@linux.vnet.ibm.com>,
jno@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices
Date: Tue, 08 Sep 2015 14:39:08 +0800 [thread overview]
Message-ID: <55EE828C.6010101@linux.vnet.ibm.com> (raw)
In-Reply-To: <55E6BDB2.1050109@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4854 bytes --]
Hi Christian:
"-no-shutdown" works fine for s390. thanks a lot for your suggestion.
I added the parameter of "-no-shutdown" only for s390-ccw-virtio as below,
_make_test_img $IMG_SIZE
+
+case "$QEMU_DEFAULT_MACHINE" in
+ s390-ccw-virtio)
+ platform_parm="-no-shutdown"
+ ;;
+ *)
+ platform_parm=""
+ ;;
+esac
+
# Give qemu some time to boot before saving the VM state
bash -c 'sleep 1; echo -e "savevm 0\nquit"' |\
- $QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG" |\
+ $QEMU $platform_parm -nographic -monitor stdio -serial none -hda
"$TEST_IMG" -machine accel=kvm |\
_filter_qemu
# Now try to continue from that VM state (this should just work)
echo quit |\
- $QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG"
-loadvm 0 |\
+ $QEMU $platform_parm -nographic -monitor stdio -serial none -hda
"$TEST_IMG" -loadvm 0 -machine accel=kvm |\
_filter_qemu
On 09/02/2015 05:13 PM, Christian Borntraeger wrote:
> Am 20.08.2015 um 16:57 schrieb Alexander Graf:
>>
>> On 20.08.15 01:20, tu bo wrote:
>>> Hi Alex:
>>>
>>> Ping you again just in case you did not get my mail :-)
>>>
>>> On 08/13/2015 03:52 PM, tu bo wrote:
>>>> Hi Alex:
>>>>
>>>> I added one disk device for test case 068(qemu/tests/qemu-iotests/068,
>>>> which is for for loading a saved VM state from a qcow2 image ),
>>>> and got the same problem for s390-virtio-ccw. Below is my steps:
>>>> 1. qemu-img create -f qcow2 scratch/t.qcow2 64M
>>>> 2. [root@r17lp42 qemu-iotests]# ../../s390x-softmmu/qemu-system-s390x
>>>> -nodefaults -nographic -monitor stdio -serial none -hda scratch/t.qcow2
>>>> QEMU 2.3.94 monitor - type 'help' for more information
>>>> (qemu) [root@r17lp42 qemu-iotests]#
>>>>
>>>> For s390-virtio, test result is as expected
>>>> 1. qemu-img create -f qcow2 scratch/t.qcow2 64M
>>>> 2. [root@r17lp42 qemu-iotests]# qemu-system-s390x -nodefaults
>>>> -nographic -monitor stdio -serial none -hda scratch/t.qcow2
>>>> QEMU 2.3.50 monitor - type 'help' for more information
>>>> (qemu) info roms
>>>> addr=0000000000009000 size=0x000ce8 mem=ram
>>>> name="/usr/share/qemu/s390-zipl.rom"
>>>> (qemu) savevm 0
>>>> (qemu)
>>>> (qemu) quit
>>>> 3.[root@r17lp42 qemu-iotests]# qemu-system-s390x -nodefaults
>>>> -nographic -monitor stdio -serial none -hda scratch/t.qcow2 -loadvm 0
>>>> QEMU 2.3.50 monitor - type 'help' for more information
>>>> (qemu)
>>>>
>>>> For x86-64, test result is as expected,
>>>> 1. [gavin@oc6333346435 qemu-iotests]$ qemu-img create -f qcow2
>>>> scratch/t.qcow2 64M
>>>> 2. [gavin@oc6333346435 qemu-iotests]$
>>>> ../../x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic
>>>> -monitor stdio -serial none -hda scratch/t.qcow2
>>>> QEMU 2.3.94 monitor - type 'help' for more information
>>>> (qemu) info roms
>>>> fw=genroms/kvmvapic.bin size=0x002400 name="kvmvapic.bin"
>>>> addr=00000000fffc0000 size=0x040000 mem=rom name="bios-256k.bin"
>>>> /rom@etc/acpi/tables size=0x200000 name="etc/acpi/tables"
>>>> /rom@etc/table-loader size=0x001000 name="etc/table-loader"
>>>> /rom@etc/acpi/rsdp size=0x000024 name="etc/acpi/rsdp"
>>>> (qemu) savevm 0
>>>> (qemu)
>>>> 3. [gavin@oc6333346435 qemu-iotests]$
>>>> ../../x86_64-softmmu/qemu-system-x86_64 -nodefaults -nographic
>>>> -monitor stdio -serial none -hda scratch/t.qcow2 -loadvm 0
>>>> QEMU 2.3.94 monitor - type 'help' for more information
>>>> (qemu)
>>>>
>>>> Could you share me why s390-virtio-ccw has different behavior with
>>>> s390-virtio & x86_64 for this scenario? thanks
>> Because the s390 folks at IBM thought it'd be cool to emit a panic
>> (read: shut down) in the ccw bootloader when there is a problem? ;)
> Which is the right thing to do on an s390. On fatal errors, disabled
> wait is used in all operating systems.
>
>> If this breaks test cases for you, please coordinate with Christian
>> Borntraeger and Eugene Dvurechenski whether it makes sense to change it.
> -no-shutdown might help, e.g. something like this
>
>
> diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests/068
> index b72e555..2185477 100755
> --- a/tests/qemu-iotests/068
> +++ b/tests/qemu-iotests/068
> @@ -52,11 +52,11 @@ echo
> _make_test_img $IMG_SIZE
> # Give qemu some time to boot before saving the VM state
> bash -c 'sleep 1; echo -e "savevm 0\nquit"' |\
> - $QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG" |\
> + $QEMU -no-shutdown -nographic -nodefaults -monitor stdio -serial none -hda "$TEST_IMG" |\
> _filter_qemu
> # Now try to continue from that VM state (this should just work)
> echo quit |\
> - $QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG" -loadvm 0 |\
> + $QEMU -no-shutdown -nographic -nodefaults -monitor stdio -serial none -hda "$TEST_IMG" -loadvm 0 |\
> _filter_qemu
>
> # success, all done
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 5648 bytes --]
prev parent reply other threads:[~2015-09-08 6:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <559CE901.1040702@linux.vnet.ibm.com>
[not found] ` <20150708112848.343434ad@bee>
[not found] ` <20150708130320.7cde018f@bee>
[not found] ` <55A62C9E.4080600@linux.vnet.ibm.com>
[not found] ` <55C0C327.3030109@linux.vnet.ibm.com>
[not found] ` <55C1BF9A.5040407@linux.vnet.ibm.com>
[not found] ` <55C40FEF.8090407@linux.vnet.ibm.com>
[not found] ` <55C84F82.9030009@linux.vnet.ibm.com>
[not found] ` <89F73019-153F-4692-B0C1-4D4C187C5E85@suse.de>
[not found] ` <55CC4CCB.3080002@linux.vnet.ibm.com>
2015-08-20 8:20 ` [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices tu bo
2015-08-20 14:57 ` Alexander Graf
2015-08-25 8:24 ` tu bo
2015-09-02 9:13 ` Christian Borntraeger
2015-09-08 6:39 ` tu bo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EE828C.6010101@linux.vnet.ibm.com \
--to=tubo@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=jno@linux.vnet.ibm.com \
--cc=mimu@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).