Re: [Qemu-devel] nvram and boot order

[Benjamin Herrenschmidt]

On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:

> > > That's horrible; if you use -boot just once it will clobber a
> > > persistent NVRAM's boot order.  I see that a means of changing the
> > > default boot order from management tools is desirable, but that
> > > shouldn't be the normal behaviour of -boot.  And the objections to (2)
> > > apply even more strongly - we'd need to translate arbitrary -boot
> > > strings to NVRAM representation which may not be at all
> > > straightforward from the information qemu has available.
> > 
> > It may not be straight forward, but it's what makes the most sense from
> > a user's PoV.
> 
> Bollocks.  Using -boot to override the normal boot sequence
> permanently changing the normal boot sequence absoultely does not make
> sense from a user's PoV.

I strongly agree with David here. -boot should not change the persistent
state.

In our case, the persistent state will have been carefully crafted by
complicated scripts by the distro installer, and while I may want to use
-boot to boot once off a cd image or similar, I certainly don't want
that to affect my nvram setting pointing to the right on-disk
bootloader.

Additionally I don't want qemu to have to understand all the intricacies
of expressing OFW boot path if we can avoid it.

Qemu gives as much info as it can and let the firmware itself inside the
guest figure things out.

In fact, I don't want Qemu to know anything about our internal nvram
format. This is a business between the guest FW and the guest OS. The
only thing qemu is allowed to do is wipe it out if asked to do so :-)

> Um.. as far as I can tell that's a point in favour of my position.  It
> makes it impossible for qemu to correctly describe boot sequences
> using these devices in the terms firmware uses internally.  On the
> other hand it certainly is possible for qemu to pass bootorder="cd"
> (or whatever) to the firmware via device tree of fw_cfg and have
> firmware locally interpret that in tersm of what it knows about
> available devices.

This is more/less what happens with -boot today. IE. If you pass "c"
SLOF looks for a bootable disk (though arguably the algorithm could be
improved), "d" for a bootable optical media etc...

We definitely want something a bit more expressive and in some case
might even be able to pass down from the command line a full path to an
actual device but we don't necessarily want qemu to understand the nvram
format of this.

Make it an expressive representation that makes sense to qemu, and let
the FW "translate" that to something it understands internally.

Cheers,
Ben.