qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] nvram and boot order


From: Anthony Liguori
Subject: Re: [Qemu-devel] nvram and boot order
Date: Tue, 16 Oct 2012 18:12:22 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

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.

Regards,

Anthony Liguori

>
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]