From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU9YA-0004bk-SV for qemu-devel@nongnu.org; Tue, 25 Aug 2015 04:25:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZU9Y5-0004Ui-S2 for qemu-devel@nongnu.org; Tue, 25 Aug 2015 04:25:46 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:57875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU9Y5-0004Sc-8U for qemu-devel@nongnu.org; Tue, 25 Aug 2015 04:25:41 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Aug 2015 18:25:37 +1000 Received: from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 877B7357804F for ; Tue, 25 Aug 2015 18:25:34 +1000 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t7P8PPGb14155940 for ; Tue, 25 Aug 2015 18:25:34 +1000 Received: from d23av02.au.ibm.com (localhost [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t7P8P0us001962 for ; Tue, 25 Aug 2015 18:25:01 +1000 Message-ID: <55DC264A.1090908@linux.vnet.ibm.com> Date: Tue, 25 Aug 2015 16:24:42 +0800 From: tu bo MIME-Version: 1.0 References: <559CE901.1040702@linux.vnet.ibm.com> <20150708112848.343434ad@bee> <20150708130320.7cde018f@bee> <55A62C9E.4080600@linux.vnet.ibm.com> <55C0C327.3030109@linux.vnet.ibm.com> <55C1BF9A.5040407@linux.vnet.ibm.com> <55C40FEF.8090407@linux.vnet.ibm.com> <55C84F82.9030009@linux.vnet.ibm.com> <89F73019-153F-4692-B0C1-4D4C187C5E85@suse.de> <55CC4CCB.3080002@linux.vnet.ibm.com> <55D58DBA.1020500@linux.vnet.ibm.com> <55D5EACC.3050105@suse.de> In-Reply-To: <55D5EACC.3050105@suse.de> Content-Type: multipart/alternative; boundary="------------010301080900090208070201" Subject: Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: Michael Mueller , qemu-devel@nongnu.org, Alexander Graf , "dahi@linux.vnet.ibm.com" , jfrei@linux.vnet.ibm.com, jno@linux.vnet.ibm.com This is a multi-part message in MIME format. --------------010301080900090208070201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > --------------010301080900090208070201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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

--------------010301080900090208070201--