Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[tu bo]

[-- Attachment #1: Type: text/plain, Size: 5212 bytes --]

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
>
>
> On 08/10/2015 03:51 PM, Alexander Graf wrote:
>>
>>
>> Am 10.08.2015 um 09:15 schrieb tu bo <tubo@linux.vnet.ibm.com 
>> <mailto:tubo@linux.vnet.ibm.com>>:
>>
>>> Dear  Alexander,  Mimu:
>>>
>>> Failure of test case 068 for s390x is caused by the commit of 
>>> "/1f68f1d36c3af09ed31a529ad69c3d09880d10fd//"
>>> //Author: Alexander Graf <agraf@suse.de>//
>>> //Date:   Tue Jun 16 23:06:33 2015 +0200//
>>> //
>>> //    s390x: Switch to s390-ccw machine as default//
>>>
>>> @@ -216,6 +216,7 @@ static void ccw_machine_class_init(ObjectClass 
>>> *oc, void *data)
>>>      mc->no_sdcard = 1;
>>>      mc->use_sclp = 1;
>>>      mc->max_cpus = 255;
>>> *+    mc->is_default = 1;*
>>>      nc->nmi_monitor_handler = s390_nmi;
>>>  }
>>>
>>> @@ -345,7 +345,6 @@ static void s390_machine_class_init(ObjectClass 
>>> *oc, void *data)
>>>      mc->no_floppy = 1;
>>>      mc->no_cdrom = 1;
>>>      mc->no_sdcard = 1;
>>> *-    mc->is_default = 1;*
>>>      nc->nmi_monitor_handler = s390_nmi;
>>>  }
>>>
>>> /Without this commit,   s390-virtio is default machine and default 
>>> ipl device is *s390-zipl.rom*
>>> [root@r17lp42 qemu]#  s390x-softmmu/qemu-system-s390x -nodefaults 
>>> -nographic -monitor stdio -serial none
>>> QEMU 2.3.94 monitor - type 'help' for more information
>>> (qemu) info cpus
>>> * CPU #0: thread_id=39761
>>> (qemu) info roms
>>> addr=0000000000009000 size=0x000ce8 mem=ram name="pc-bios/s390-zipl.rom"
>>>
>>> With this commit,  s390-virtio-ccw is default machine and default 
>>> ipl device is *s390-ccw.img*, When running
>>> "s390x-softmmu/qemu-system-s390x -nodefaults -nographic -monitor 
>>> stdio -serial none -machine accel=kvm" ,  the cpu status is
>>> *halted* which causes the failure of test case 068.
>>> [root@r17lp42 qemu]# s390x-softmmu/qemu-system-s390x -nodefaults 
>>> -nographic -monitor stdio -serial none -machine accel=kvm
>>> QEMU 2.3.94 monitor - type 'help' for more information
>>> (qemu) info cpus
>>> * CPU #0: *(halted)* thread_id=39746
>>> (qemu) info roms
>>> addr=0000000007e00000 size=0x002dd0 mem=ram name="phdr #2: 
>>> /disks/bo.home/vs1403/qemu/pc-bios/s390-ccw.img"
>>> addr=0000000007e03f00 size=0x01d100 mem=ram name="phdr #3: 
>>> /disks/bo.home/vs1403/qemu/pc-bios/s390-ccw.img"
>>>
>>> With this commit,  when running "s390x-softmmu/qemu-system-s390x 
>>> -nodefaults -nographic -monitor stdio -serial none", then qemu will 
>>> exit as below,
>>> [root@r17lp42 qemu]#  s390x-softmmu/qemu-system-s390x -nodefaults 
>>> -nographic -monitor stdio -serial none
>>> QEMU 2.3.94 monitor - type 'help' for more information
>>> (qemu) [root@r17lp42 qemu]#
>>>
>>> Is this the expected behavior of s390-virtio-ccw and s390-ccw.img?  
>>> thanks
>>
>> Yes, the ccw machine finds no device to load from and errors out, 
>> exiting thr vm. The s390-virtio boot loader wasn't smart enough for 
>> that and just hung iirc.
>>
>>
>> Alex
>>
>


[-- Attachment #2: Type: text/html, Size: 7829 bytes --]

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[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? ;)

If this breaks test cases for you, please coordinate with Christian
Borntraeger and Eugene Dvurechenski whether it makes sense to change it.


Alex

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[tu bo]

[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]

Hi Christian:

Test case 068(qemu/tests/qemu-iotests/068, which is for loading a saved 
VM state from a qcow2 image)
was broken because s390-virtio-ccw uses the new bootloader of 
s390-ccw.img, instead of s390-zipl.rom.

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]#
3. I can get error message from s390-ccw.img as below,
Using guessed DASD geometry.
Using ECKD scheme (block size  4096),
CDL
! No zIPL section in IPL2 record. !

in qemu/pc-bios/s390-ccw/bootmap.c
     213 static void ipl_eckd_cdl(void)
     214 {
     215     XEckdMbr *mbr;
     216     Ipl2 *ipl2 = (void *)sec;
     217     IplVolumeLabel *vlbl = (void *)sec;
     218     block_number_t block_nr;
     219
     220     /* we have just read the block #0 and recognized it as "IPL1" */
     *221     sclp_print("CDL\n");*
     222
     223     memset(sec, FREE_SPACE_FILLER, sizeof(sec));
     224     read_block(1, ipl2, "Cannot read IPL2 record at block 1");
     225
     226     mbr = &ipl2->u.x.mbr;
     227     IPL_assert(magic_match(mbr, ZIPL_MAGIC), "*No zIPL section in IPL2 record.*");

We may have two solutions,
1. providing a very small linux image(assuming name is t.qcow2) for s390x which can be IPLed, via "s390x-softmmu/qemu-system-s390x
-nodefaults -nographic -monitor stdio -serial none -hda scratch/t.qcow2"
2. disable test case 068 for s390x

What's your opinion?  thanks


On 08/20/2015 10:57 PM, Alexander Graf wrote:
>
> 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? ;)
>
> If this breaks test cases for you, please coordinate with Christian
> Borntraeger and Eugene Dvurechenski whether it makes sense to change it.
>
>
> Alex
>


[-- Attachment #2: Type: text/html, Size: 4769 bytes --]

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[Christian Borntraeger]

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

Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices

[tu bo]

[-- 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 --]