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

[Nikunj A Dadhania]

On Fri, 5 Oct 2012 10:34:16 +1000, David Gibson <address@hidden> wrote:
> 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/address@hidden/address@hidden,1
> > /spapr-vio-bridge/spapr-vscsi/address@hidden/address@hidden,0"
> 
> Ok, so I've just started looking at the bootindex stuff.  What
> function is generating these strings?

get_boot_devices_list gives you the above

> 
> 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?

Even if the bootindex is taken care, there is still -boot that has to be
handled. Or we just need to drop -boot handling? In that case what
should we look at when there is no boot-index and nothing in nvram.

Regards
Nikunj