From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCZc-00027N-I3 for qemu-devel@nongnu.org; Tue, 08 Sep 2015 02:40:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZCZZ-0006Bq-8V for qemu-devel@nongnu.org; Tue, 08 Sep 2015 02:40:08 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:32794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZCZY-00064J-M0 for qemu-devel@nongnu.org; Tue, 08 Sep 2015 02:40:05 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 8 Sep 2015 16:40:01 +1000 Received: from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id 5CE872BB0052 for ; Tue, 8 Sep 2015 16:39:59 +1000 (EST) Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t886dmnN5177522 for ; Tue, 8 Sep 2015 16:39:56 +1000 Received: from d23av04.au.ibm.com (localhost [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t886dQjT031758 for ; Tue, 8 Sep 2015 16:39:26 +1000 Message-ID: <55EE828C.6010101@linux.vnet.ibm.com> Date: Tue, 08 Sep 2015 14:39:08 +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> <55E6BDB2.1050109@de.ibm.com> In-Reply-To: <55E6BDB2.1050109@de.ibm.com> Content-Type: multipart/alternative; boundary="------------010801080407040400040708" 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 , Alexander Graf Cc: qemu-devel@nongnu.org, "dahi@linux.vnet.ibm.com" , jfrei@linux.vnet.ibm.com, Michael Mueller , jno@linux.vnet.ibm.com This is a multi-part message in MIME format. --------------010801080407040400040708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > > > > --------------010801080407040400040708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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

--------------010801080407040400040708--