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

[Gleb Natapov <gleb@redhat.com>]

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?

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

--
			Gleb.