Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Tue, Oct 16, 2012 at 06:12:22PM -0500, Anthony Liguori wrote:
> Peter Maydell <address@hidden> writes:
> 
> > On 16 October 2012 20:55, Anthony Liguori <address@hidden> 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.
> >>
> >> 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.
> >>
> >> 2) In the absence of a persistent NVRAM, a ephemeral NVRAM should be
> >>    generated with a reasonable default boot order.
> >>
> >> 3) In the absence of -boot or ,bootindex=, the system should boot from
> >>    order specified in NVRAM.
> >>
> >> 4) If -boot is specified, the parameter should alter the contents of
> >>    NVRAM to change the boot order to what is specified by -boot.
> >>
> >> 5) If ,bootorder is specified, it should take predence over -boot.
> >>
> >> 6) ,bootorder= should also alter the contents of NVRAM to determine the
> >>    boot order.
> >
> > What's the rationale for 6? It seems a bit odd for a command line
> > option to randomly mangle the NVRAM...
> 
> The use case is to have a consistent view of the boot order within the
> guest and in the host while still having the ability to edit the
> persistent boot order within the guest.
> 
> If you look at my other note in this thread, one way to achieve this is
> to have the boot order "owned" by QEMU with the guest making fw_cfg
> calls to modify it.  It would be persisted in a portion of the NVRAM
> reserved for QEMU's use.

That's not necessarily compatible with established guest visible
platform NVRAM semantics.

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