qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: tu bo <tubo@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Michael Mueller <mimu@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	"dahi@linux.vnet.ibm.com" <dahi@linux.vnet.ibm.com>,
	jfrei@linux.vnet.ibm.com, jno@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [kvm-s390] qemu-system-s390x: cannot use stdio by multiple character devices
Date: Tue, 25 Aug 2015 16:24:42 +0800	[thread overview]
Message-ID: <55DC264A.1090908@linux.vnet.ibm.com> (raw)
In-Reply-To: <55D5EACC.3050105@suse.de>

[-- 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 --]

  reply	other threads:[~2015-08-25  8:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2015-09-02  9:13                       ` Christian Borntraeger
2015-09-08  6:39                         ` tu bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DC264A.1090908@linux.vnet.ibm.com \
    --to=tubo@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=jno@linux.vnet.ibm.com \
    --cc=mimu@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).