Re: [Qemu-devel] nvram and boot order

[Anthony Liguori <aliguori@us.ibm.com>]

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.

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

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

Regards,

Anthony Liguori

> I see -boot and -bootorder as ways to *temporarily* override whatever
> setting was put in nvram by the guest. The nvram is typically populated
> by the distro installer (though sometimes by hand by the user). One may
> want to just temporarily boot from a CD (rescue for example, or to test
> a live CD or something ...), that doesn't mean the permanent setting
> should be altered.
>
> I would pass -boot and -bootorder to SLOF like we pass the current
> bootlist today and let it deal with it, I wouldn't touch the nvram.
>
> Cheers,
> Ben.