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
