Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Wed, Oct 17, 2012 at 01:17:28PM -0500, Anthony Liguori wrote:
> David Gibson <address@hidden> writes:
> 
> > On Tue, Oct 16, 2012 at 02:55:21PM -0500, Anthony Liguori wrote:
> >> 
> >> We discussed nvram and it's interaction with boot order in today's KVM
> >> call.  Here's the outcome.  This list is completely incremental so it's
> >> fine to start with 1-4, for instance, as long as we eventually get
> >> to 6.
> >
> > Sorry I missed the call.  I was actually awake at the time, but I was
> > pretty exhausted and forgot to reset my clock from my trip away.
> >
> >> Today, on x86, we implement up to (5) but we don't persist NVRAM.
> >> 
> >> 1) We should modify QEMUMachine to specify that a machine does not want
> >>    a default boot order.  Ideally, this would be done by adding a new
> >>    default_boot_order that is set to "cad" explicitly in all machines
> >>    allowing a machine to remove that entry.  At any rate, this allows a
> >>    machine to receive a NULL boot order when -boot isn't used and take an
> >>    appropriate action accordingly.
> >
> > This sounds good to me.  I'll sync with Avik and Nikunj and get onto
> > implementing that immediately for our case.
> >
> >> 2) In the absence of a persistent NVRAM, a ephemeral NVRAM should be
> >>    generated with a reasonable default boot order.
> >
> > This seems.. dubious to me.  It means that qemu needs to know the
> > firmware representation of the boot devices, which is not necessarily
> > easy.  And the platforms's specific NVRAM representation may not even
> > allow an arbitrary list.
> 
> So then how can boot ordering even be implemented?  If you're going to
> say through a PV interface, then that means you're adding knowledge to
> the guest.  So why can't NVRAM be that pv interface?

Depends on the platform.  In our case we'd use the device tree, just
like we do now.  The -boot string (if specified) is passed as a
property in /chosen, firmware interprets it into its internal boot
ordering.  fw_cfg would work too, for platforms which use it.

> The problem to avoid here is having two disjoint boot lists--one
> controlled by the firmware and one controlled by the host.  This is not
> user friendly.

On the contrary, I think having the "once-only-just-this-boot" command
line override list and the permanent default boot list being separate
is *exactly* what users will expect.

> >> 4) If -boot is specified, the parameter should alter the contents of
> >>    NVRAM to change the boot order to what is specified by -boot.
> >
> > 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.

> These are all interfaces that we control, there's not a whole lot of
> reason we can't make it all work together.
> 
> >
> >> 5) If ,bootorder is specified, it should take predence over -boot.
> >
> > Sure.
> >
> >> 6) ,bootorder= should also alter the contents of NVRAM to determine the
> >>    boot order.
> >
> > And, same objections as (4).
> >
> >
> > It seems to me that this spec is focussing far too much on
> > implementation rather than semantics.  I think that for all platforms
> > the outline of the boot order semantics should be the same, that is:
> >     if bootindex is specified:
> >             use the bootindex order
> >     else if -boot is specified:
> >             use the -boot order
> >     else:
> >             use platform specific default behaviour
> >
> > The last option may depend on the contents of NVRAM or other platform
> > specific information.  More importantly though, how best to achieve
> > these semantics may depend on platform specifics (including how
> > flexible its NVRAM boot order representation is, if any).
> 
> The problem I have with this is that you're lumping all guest boot order
> interaction into "platform specific default behavior".
> 
> There are cases where the bootable devices simply aren't known to QEMU.
> I think benh gave the example of a FC adapter being passed through to
> the guest.  QEMU has no clue what LUNs are available to be booted from.

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.

> If we're going to allow the host to control boot order, we need to avoid
> having a split brain behavior here.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson