Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting

[David Gibson <dwg@au1.ibm.com>]

On Thu, Oct 04, 2012 at 04:25:28PM +0530, Avik Sil wrote:
> On 09/27/2012 03:21 PM, Gleb Natapov wrote:
> >On Thu, Sep 27, 2012 at 11:33:31AM +0200, Alexander Graf wrote:
> >>
> >>On 27.09.2012, at 11:29, Benjamin Herrenschmidt wrote:
> >>
> >>>On Thu, 2012-09-27 at 14:51 +0530, Avik Sil wrote:
> >>>>Hi,
> >>>>
> >>>>We would like to get a method to boot from devices provided in -boot
> >>>>arguments in qemu when the 'boot-device' is set in nvram for pseries
> >>>>machine. I mean the boot device specified in -boot should get a
> >>>>precedence over the 'boot-device' specified in nvram.
> >>>>
> >>>>At the same time, when -boot is not provided, i.e., the default boot
> >>>>order "cad" is present, the device specified in nvram 'boot-device'
> >>>>should get precedence if it is set.
> >>>>
> >>>>What should be the elegant way to implement this requirement?
> >>>>Suggestions welcome.
> >>>
> >>>Actually I think it's a more open question. We have essentially two
> >>>things at play here:
> >>>
> >>>- With the new nvram model, the firmware can store a boot device
> >>>reference in it, which is standard OF practice, and in fact the various
> >>>distro installers are going to do just that
> >>>
> >>>- Qemu has its own boot order thingy via -boot, which we loosely
> >>>translate as c = first bootable disk we find (actually first disk we
> >>>find, we should probably make the algorithm a bit smarter), d = first
> >>>cdrom we find, n = network , ... We pass that selection (boot list) down
> >>>to SLOF via a device-tree property.
> >>>
> >>>The question is thus what precedence should we give them. I was
> >>>initially thinking that an explicit qemu boot list should override the
> >>>firmware nvram setting but I'm now not that sure anymore.
> >>>
> >>>The -boot list is at best a "blurry" indication of what type of device
> >>>the user wants ... The firmware setting in nvram is precise.
> >>
> >>IIRC gleb had implemented a specific boot order thing. Gleb, mind to enlighten us? :)
> >>
> >Yes, forget about -boot. It is deprecated :) You should use bootindex
> >(device property) to set boot priority. It constructs OF device path
> >and passes it to firmware. There is nothing "blurry" about OF device
> >path. The problem is that it works reasonably well with legacy BIOS
> >since it is enough to specify device to boot from, but with EFI (OF is
> >the same I guess) it is not enough to point to a device to boot from,
> >but you also need to specify a file you want to boot and this is where
> >bootindex approach fails. If EFI would specify default file to boot from
> >firmware could have used it, but EFI specifies it only for removable media
> >(what media is not removable this days, especially with virtualization?).
> >We can add qemu parameter to specify file to boot, but how users should
> >know the name of the file?
> >
> I looked at the bootindex stuff and found that when the bootindex is
> specified for the disk and cdrom it generates a string like:
> 
> "/spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,1
> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,0"

Ok, so I've just started looking at the bootindex stuff.  What
function is generating these strings?

We should also be able to get the raw bootindex values for a qdev,
yes?  I was thinking we could instead copy those values into the
device tree when we populate it.  The trouble is that we don't
actually generate (in qemu) nodes for individual disks under a vscsi,
or for individual PCI devices under the host bridge (that's done by
SLOF).  Still thinking...

An aside, I'm thinking that once we do get bootindex working, then
boot devices specified in NVRAM should have priority below all devices
with explicit supplied bootindex, but above any that don't.  Does that
seem right to you?

> Now converting/translating this to OF device path is going to be
> much trickier and might not be proper. So I propose a simple
> solution by introducing a global flag that checks if explicit -boot
> parameter is provided or not. The presence of this parameter is
> verified in SLOF firmware. The flag had to be introduced as
> boot_devices defaults to "cad" instead of null and passed to
> machine->init().

So, personally, I think this is quite a reasonable interim measure
until we figure out how to do bootindex.  I will fold it into our
internal tree for now, even if the qemu people are going to bitch and
moan about its imperfections.  Can you send me a clean copy with
commit message, please?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson