All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.