From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
qemu-devel Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1/1] s390: IPL device for s390
Date: Tue, 08 May 2012 20:54:06 +0200 [thread overview]
Message-ID: <4FA96BCE.1040100@de.ibm.com> (raw)
In-Reply-To: <26FC36DC-33B0-4C38-B67E-20812F527046@suse.de>
> Well, the only shortcomings I'm aware of of the external IPL are:
>
> * You lose the boot menu. All you get is "entry 0", "entry 1", etc. as the description is not part of the boot map
> * You can't choose different entries during runtime. Doing a reboot of a VM and selecting a different entry won't work.
>
> The former is pretty annoying if you don't know all of your VMs by heart. The latter is an issue when you don't own the qemu process,
> but do own the VM. Think of a hosted environment.
Those are valid points. Regarding the former, I see two things that we might do here:
1. have the current zipl-"bios" as a fallback if the user does not specify an s390-ipl device.
That should be pretty easy and might even have the advantage to minimize the surprise to
existing users of kvm on s390(are there any?). If the user provides an s390-ipl device
then this is a conscious decision. (I will move the specific virtio-zipl bios code into
the s390-ipl device nevertheless,see below for rationale)
2. I will check with the zipl maintainer if we could sneak in the necessary information in
the boot map, the program table or something else (e.g. defining an component_description,
after component_execute). It just have to be compatible with the layout that the firmware
loader expects. Not sure yet, if this will work out
I definitely want to concentrate all booting in this device: kernel, zipl-virtio, firmware
loader and everything else, because on system_reset we have to reset the cpus and set
the PSW accordingly. As a device we are being called during reset at the right time.
Does that make sense? If yes I will try to refresh that patch as outlined above
Christian
next prev parent reply other threads:[~2012-05-08 18:54 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 [this message]
2012-05-08 19:18 ` Alexander Graf
2012-05-08 19:16 ` Anthony Liguori
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=4FA96BCE.1040100@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=agraf@suse.de \
--cc=aliguori@us.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).