Re: [Qemu-devel] nvram and boot order

[David Gibson <dwg@au1.ibm.com>]

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.

> 3) In the absence of -boot or ,bootindex=, the system should boot from
>    order specified in NVRAM.

Sure, makes sense.

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

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

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