* Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices [not found] ` <55CC4CCB.3080002@linux.vnet.ibm.com> @ 2015-08-20 8:20 ` tu bo 2015-08-20 14:57 ` Alexander Graf 0 siblings, 1 reply; 5+ messages in thread From: tu bo @ 2015-08-20 8:20 UTC (permalink / raw) To: Alexander Graf; +Cc: dahi@linux.vnet.ibm.com, Michael Mueller, qemu-devel [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices 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 0 siblings, 2 replies; 5+ messages in thread From: Alexander Graf @ 2015-08-20 14:57 UTC (permalink / raw) To: tu bo Cc: Michael Mueller, Christian Borntraeger, qemu-devel, dahi@linux.vnet.ibm.com, jfrei, jno 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices 2015-08-20 14:57 ` Alexander Graf @ 2015-08-25 8:24 ` tu bo 2015-09-02 9:13 ` Christian Borntraeger 1 sibling, 0 replies; 5+ messages in thread From: tu bo @ 2015-08-25 8:24 UTC (permalink / raw) To: Christian Borntraeger Cc: Michael Mueller, qemu-devel, Alexander Graf, dahi@linux.vnet.ibm.com, jfrei, jno [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices 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 1 sibling, 1 reply; 5+ messages in thread From: Christian Borntraeger @ 2015-09-02 9:13 UTC (permalink / raw) To: Alexander Graf, tu bo Cc: dahi@linux.vnet.ibm.com, jfrei, jno, Michael Mueller, qemu-devel 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices 2015-09-02 9:13 ` Christian Borntraeger @ 2015-09-08 6:39 ` tu bo 0 siblings, 0 replies; 5+ messages in thread From: tu bo @ 2015-09-08 6:39 UTC (permalink / raw) To: Christian Borntraeger, Alexander Graf Cc: qemu-devel, dahi@linux.vnet.ibm.com, jfrei, Michael Mueller, jno [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-08 6:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 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).