Re: [Qemu-devel] nvram and boot order

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

On Tue, Oct 16, 2012 at 03:55:17PM -0500, Anthony Liguori wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> 
> > On Tue, 2012-10-16 at 14:55 -0500, Anthony Liguori wrote:
> >> 
> >> 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
> >
> > That's where I disagree. At least for us... I don't see why -boot or
> > -bootorder should alter the nvram content.
> 
> Well, I think what we really need is the ability to permanently change
> the boot order and the ability to select a temporary boot device.

Sure.

> Which one of the two semantics the existing options take vs. new options
> is less important IMHO.

As I've said elsewhere, I strongly disagree.  -boot does not make a
permanent change now, and it shouldn't do so in future.

> > The plan is to have the nvram content essentially in control of SLOF
> > (ie. the BIOS in x86 land). Qemu doesn't know much of anything appart
> > from providing the storage for it.
> 
> One thing I was thinking is to do the opposite with x86...
> 
> CMOS is 128 bytes.  I was thinking we could have a much larger persisted
> CMOS with the remaining space under control of fw_cfg.
> 
> That way, SeaBIOS could issue fw_cfg commands to alter the boot order
> permanently and QEMU would be responsible for persisting that in the
> remaining CMOS space.
> 
> It might make sense to do the same thing for Power.  Leave a portion of
> the NVRAM space under QEMU's control for this sort of thing.

That doesn't really work.  The PAPR NVRAM has an internal partitioning
scheme, so we could define a new partition type for qemu use.  There's
not really any point doing so for qemu to communicate information to
the firmware, because that's more easily done via the device tree.  It
could be used for the firmware to communicate data to qemu to persist,
I suppose.

But in any case it's no good for bootorder, because there are existing
guest side tools - not just the firmware - which expect the boot order
to be stored in the PAPR described way within the NVRAM.  Inventing a
new method for qemu won't work with those existing tools which would
rather defeat the purpose.

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