From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSL5X-0001gU-T6 for qemu-devel@nongnu.org; Thu, 20 Aug 2015 04:20:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSL5T-0000EM-MR for qemu-devel@nongnu.org; Thu, 20 Aug 2015 04:20:43 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:37574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSL5S-0000An-Nq for qemu-devel@nongnu.org; Thu, 20 Aug 2015 04:20:39 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 20 Aug 2015 13:50:32 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id CE644E0024 for ; Thu, 20 Aug 2015 13:49:50 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay03.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t7K8KT0V56033328 for ; Thu, 20 Aug 2015 13:50:29 +0530 Received: from d28av04.in.ibm.com (localhost [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t7K8KCkV022580 for ; Thu, 20 Aug 2015 13:50:13 +0530 Message-ID: <55D58DBA.1020500@linux.vnet.ibm.com> Date: Thu, 20 Aug 2015 16:20:10 +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> In-Reply-To: <55CC4CCB.3080002@linux.vnet.ibm.com> Content-Type: multipart/alternative; boundary="------------000701050000070909020703" 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: Alexander Graf Cc: "dahi@linux.vnet.ibm.com" , Michael Mueller , qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------000701050000070909020703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > >: >> >>> Dear Alexander, Mimu: >>> >>> Failure of test case 068 for s390x is caused by the commit of >>> "/1f68f1d36c3af09ed31a529ad69c3d09880d10fd//" >>> //Author: Alexander Graf // >>> //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 >> > --------------000701050000070909020703 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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>:

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



--------------000701050000070909020703--