From: Anthony Liguori <aliguori@us.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
Alexander Graf <agraf@suse.de>,
qemu-devel Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
Date: Tue, 08 May 2012 14:16:33 -0500 [thread overview]
Message-ID: <4FA97111.8@us.ibm.com> (raw)
In-Reply-To: <4FA91267.5050306@de.ibm.com>
On 05/08/2012 07:32 AM, Christian Borntraeger wrote:
> On 04/05/12 20:12, Alexander Graf wrote:
>>
>> On 04.05.2012, at 16:02, Christian Borntraeger wrote:
>>
>>> On 04/05/12 16:00, Christian Borntraeger wrote:
>>>>>> An IPL (booting) on s390 of SCSI disks is done by a firmware component.
>>>>>> Lets implement this scheme as an qemu device that also allows to
>>>>>> configure the IPL like the HMC. We have a parameter iplid that
>>>>>> refers to a disk device and a load parm that specifies the entry
>>>>>> on the disk to be ipled. We also provide a default device
>>>>>> if no -device s390-ipl statement is given.
>>>>>
>>>>> Any reason we can't do this in guest firmware code?
>>>>
>>>> Conceptually guest firmware does not exist in the guest address space
>>>> on s390. It is separate in a storage area called HSA.
>>>> (you could say the existing hardware is semi-hosted, you cant buy it bare
>>>> metal.
>>>> Doing the boot code in guest address space will fail if the guest firmware
>>>> address collides with the addresses specified by a bootmap.
>>>
>>> Or in other words, this code is closer to the real s390 boxes.
>>
>> Yeah, I see the point. I'd really like to get Anthony's comments on this one first though.
>
> Right.
>
> Anthony, this is the prototype of the IPL device that we have talked about some weeks
> ago. Is an external device to do the IPL process for s390 still ok with you?
I don't really understand the point about collision. If you chain load
carefully, you ought to be able to relocate or something like that I would imagine.
But at any rate, for these semi-hosted platforms, I don't see a lot better
choices than doing these things as devices since there's no "real hardware" to
model.
So doing this as a device and limiting it to s390 seems like the right strategy
to me.
Regards,
Anthony Liguori
>
> Christian
>
prev parent reply other threads:[~2012-05-08 19:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 13:43 [Qemu-devel] [PATCH 0/1] RFC: ipl device for s390 Christian Borntraeger
2012-05-04 13:44 ` [Qemu-devel] [PATCH 1/1] s390: IPL " Christian Borntraeger
2012-05-04 13:53 ` Alexander Graf
2012-05-04 14:00 ` Christian Borntraeger
2012-05-04 14:02 ` Christian Borntraeger
2012-05-04 18:12 ` Alexander Graf
2012-05-08 12:32 ` Christian Borntraeger
2012-05-08 12:40 ` Alexander Graf
2012-05-08 14:43 ` Christian Borntraeger
2012-05-08 14:53 ` Alexander Graf
2012-05-08 18:54 ` Christian Borntraeger
2012-05-08 19:18 ` Alexander Graf
2012-05-08 19:16 ` Anthony Liguori [this message]
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=4FA97111.8@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=graalfs@linux.vnet.ibm.com \
--cc=jfrei@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).