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

[Alexander Graf]

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

> However if we make the nvram override qemu, then it's trickier to
> force-boot from, let's say, a rescue CD. The user would have to stop the
> SLOF boot process by pressing a key then manually type something like
> "boot cdrom".
> 
> Maybe the right approach is "in between", and is that the primary driver
> is the -boot argument. For each entry in the boot list, if it's "c", use
> the configured boot-device or fallback to the automatic guess SLOF tries
> to do today in absence of a boot-device. If it's "d" or "n" force it
> respectively to cdrom or network...
> 
> I think there is no perfect solution here. What do you guys think is the
> less user unfriendly ?

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

> Eventually we should try to implement some sort of interactive boot
> device selection in SLOF, such as SMS does on pseries, but that will
> take a bit of time.

That would be en par with the bootmenu on x86 :). Please check out how x86 
models these things. It could sure be interesting for pseries.


Alex