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

[Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>]

On Thu, 27 Sep 2012 11:51:36 +0200, Gleb Natapov <gleb@redhat.com> 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. 

If the user does not set bootindex, qemu would decide the bootindex?  

If it does, there will be a default bootindex. Then the problem still
remains, qemu decided the boot-order, in which case we would want to
pick the nvram based setting. This is again difficult to distinguish.

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

By file I suppose you mean OF device-path. 

> > 
> > I think the command line should override anything user specified. So basically:
> > 
> >   * user defined -boot option (or bootindex magic from Gleb)
> >   * nvram
> >   * fallback to default
> > 

Regards
Nikunj