From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSRHT-00007T-Id for qemu-devel@nongnu.org; Thu, 20 Aug 2015 10:57:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSRHO-0005LT-RI for qemu-devel@nongnu.org; Thu, 20 Aug 2015 10:57:26 -0400 Received: from mx2.suse.de ([195.135.220.15]:39283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSRHO-0005Kw-Hy for qemu-devel@nongnu.org; Thu, 20 Aug 2015 10:57:22 -0400 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> From: Alexander Graf Message-ID: <55D5EACC.3050105@suse.de> Date: Thu, 20 Aug 2015 07:57:16 -0700 MIME-Version: 1.0 In-Reply-To: <55D58DBA.1020500@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: tu bo Cc: Michael Mueller , Christian Borntraeger , qemu-devel@nongnu.org, "dahi@linux.vnet.ibm.com" , jfrei@linux.vnet.ibm.com, jno@linux.vnet.ibm.com 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