[Qemu-devel] nvram and boot order

[Qemu-devel] nvram and boot order

[Anthony Liguori]

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.

Regards,

Anthony Liguori

Re: [Qemu-devel] nvram and boot order

[Benjamin Herrenschmidt]

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.

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.

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.

Re: [Qemu-devel] nvram and boot order

[Peter Maydell]

On 16 October 2012 20:55, Anthony Liguori <aliguori@us.ibm.com> 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...

-- PMM

Re: [Qemu-devel] nvram and boot order

[Anthony Liguori]

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.

Re: [Qemu-devel] nvram and boot order

[Anthony Liguori]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 16 October 2012 20:55, Anthony Liguori <aliguori@us.ibm.com> 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

Re: [Qemu-devel] nvram and boot order

[David Gibson]

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

Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Tue, Oct 16, 2012 at 06:12:22PM -0500, Anthony Liguori wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> 
> > On 16 October 2012 20:55, Anthony Liguori <aliguori@us.ibm.com> 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

Re: [Qemu-devel] nvram and boot order

[Gleb Natapov]

On Wed, Oct 17, 2012 at 07:07:53AM +1100, Benjamin Herrenschmidt wrote:
> 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.
> 
> 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.
> 
> 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.
> 
Agree with you and David. This is not QEMU busyness to touch nvram
content. For all we know it may be encrypted by a key knows only to
the firmware.

--
			Gleb.

Re: [Qemu-devel] nvram and boot order

[Anthony Liguori]

David Gibson <dwg@au1.ibm.com> writes:

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

So then how can boot ordering even be implemented?  If you're going to
say through a PV interface, then that means you're adding knowledge to
the guest.  So why can't NVRAM be that pv interface?

The problem to avoid here is having two disjoint boot lists--one
controlled by the firmware and one controlled by the host.  This is not
user friendly.

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

It may not be straight forward, but it's what makes the most sense from
a user's PoV.

These are all interfaces that we control, there's not a whole lot of
reason we can't make it all work together.

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

The problem I have with this is that you're lumping all guest boot order
interaction into "platform specific default behavior".

There are cases where the bootable devices simply aren't known to QEMU.
I think benh gave the example of a FC adapter being passed through to
the guest.  QEMU has no clue what LUNs are available to be booted from.

If we're going to allow the host to control boot order, we need to avoid
having a split brain behavior here.

Regards,

Anthony Liguori

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

Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Wed, Oct 17, 2012 at 01:17:28PM -0500, Anthony Liguori wrote:
> David Gibson <dwg@au1.ibm.com> writes:
> 
> > 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.
> 
> So then how can boot ordering even be implemented?  If you're going to
> say through a PV interface, then that means you're adding knowledge to
> the guest.  So why can't NVRAM be that pv interface?

Depends on the platform.  In our case we'd use the device tree, just
like we do now.  The -boot string (if specified) is passed as a
property in /chosen, firmware interprets it into its internal boot
ordering.  fw_cfg would work too, for platforms which use it.

> The problem to avoid here is having two disjoint boot lists--one
> controlled by the firmware and one controlled by the host.  This is not
> user friendly.

On the contrary, I think having the "once-only-just-this-boot" command
line override list and the permanent default boot list being separate
is *exactly* what users will expect.

> >> 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.
> 
> It may not be straight forward, but it's what makes the most sense from
> a user's PoV.

Bollocks.  Using -boot to override the normal boot sequence
permanently changing the normal boot sequence absoultely does not make
sense from a user's PoV.

> These are all interfaces that we control, there's not a whole lot of
> reason we can't make it all work together.
> 
> >
> >> 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).
> 
> The problem I have with this is that you're lumping all guest boot order
> interaction into "platform specific default behavior".
> 
> There are cases where the bootable devices simply aren't known to QEMU.
> I think benh gave the example of a FC adapter being passed through to
> the guest.  QEMU has no clue what LUNs are available to be booted from.

Um.. as far as I can tell that's a point in favour of my position.  It
makes it impossible for qemu to correctly describe boot sequences
using these devices in the terms firmware uses internally.  On the
other hand it certainly is possible for qemu to pass bootorder="cd"
(or whatever) to the firmware via device tree of fw_cfg and have
firmware locally interpret that in tersm of what it knows about
available devices.

> If we're going to allow the host to control boot order, we need to avoid
> having a split brain behavior here.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> 

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

Re: [Qemu-devel] nvram and boot order

[Benjamin Herrenschmidt]

On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:

> > > 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.
> > 
> > It may not be straight forward, but it's what makes the most sense from
> > a user's PoV.
> 
> Bollocks.  Using -boot to override the normal boot sequence
> permanently changing the normal boot sequence absoultely does not make
> sense from a user's PoV.

I strongly agree with David here. -boot should not change the persistent
state.

In our case, the persistent state will have been carefully crafted by
complicated scripts by the distro installer, and while I may want to use
-boot to boot once off a cd image or similar, I certainly don't want
that to affect my nvram setting pointing to the right on-disk
bootloader.

Additionally I don't want qemu to have to understand all the intricacies
of expressing OFW boot path if we can avoid it.

Qemu gives as much info as it can and let the firmware itself inside the
guest figure things out.

In fact, I don't want Qemu to know anything about our internal nvram
format. This is a business between the guest FW and the guest OS. The
only thing qemu is allowed to do is wipe it out if asked to do so :-)

> Um.. as far as I can tell that's a point in favour of my position.  It
> makes it impossible for qemu to correctly describe boot sequences
> using these devices in the terms firmware uses internally.  On the
> other hand it certainly is possible for qemu to pass bootorder="cd"
> (or whatever) to the firmware via device tree of fw_cfg and have
> firmware locally interpret that in tersm of what it knows about
> available devices.

This is more/less what happens with -boot today. IE. If you pass "c"
SLOF looks for a bootable disk (though arguably the algorithm could be
improved), "d" for a bootable optical media etc...

We definitely want something a bit more expressive and in some case
might even be able to pass down from the command line a full path to an
actual device but we don't necessarily want qemu to understand the nvram
format of this.

Make it an expressive representation that makes sense to qemu, and let
the FW "translate" that to something it understands internally.

Cheers,
Ben.

Re: [Qemu-devel] nvram and boot order

[Alexander Graf]

On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
> 
>>>> 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.
>>> 
>>> It may not be straight forward, but it's what makes the most sense from
>>> a user's PoV.
>> 
>> Bollocks.  Using -boot to override the normal boot sequence
>> permanently changing the normal boot sequence absoultely does not make
>> sense from a user's PoV.
> 
> I strongly agree with David here. -boot should not change the persistent
> state.

I think Anthony and you are looking at 2 different use cases, each with their own sane reasoning.

You want to have the chance to override the boot order temporarily for things like cd boot or quick guest rescue missions.

You also want to be able to permanently change the guest's boot order from a management tool. At that same place you want to be able to display it, so you don't have to boot your vm to know what it would be doing.

As for device detection logic, both face the same problems. You need to be able to say 'boot from cd-rom first temporarily' just the same as you need to be able to say 'boot from the first cd-rom as first boot option permanently'. The permanent change needs to be possible with the vm turned off though.

I suppose that Anthony's reasoning is that we can implement temporary in the management layer (or even qemu) if we have the permanent mechanism, by switching back to the previous state after shutdown if the guest written boot order didn't change.

I don't mind personally if we have one interface for temporary and persistent or 2 separate ones, but I think we should aim for having both options available in the long run. Though doing permanent changes first and reverting them later could raise problems when you kill your vm, since that wouldn't clean up the temporary change.

> 
> In our case, the persistent state will have been carefully crafted by
> complicated scripts by the distro installer, and while I may want to use
> -boot to boot once off a cd image or similar, I certainly don't want
> that to affect my nvram setting pointing to the right on-disk
> bootloader.
> 
> Additionally I don't want qemu to have to understand all the intricacies
> of expressing OFW boot path if we can avoid it.

Yes, the same problem as EFI for example is facing. The solution here is as simple as it gets: a new device name space. Instead of having a boot list entry saying 'boot from device x, part y, file z' you would get an entry saying 'boot from /qemu/disk0' and leave the rest to the firmware. The good thing about this approach is that it again is persistable and can be used in boot order lists. So you can directly translate -boot cd into /qemu/disk0,/qemu/cdrom. And if you screwed up your guest boot config, just put that order in by hand into permanent config.

> 
> Qemu gives as much info as it can and let the firmware itself inside the
> guest figure things out.

Yes, that's the only chance we have really. Even for bootindex, which could for example get translated to /qemu/pci/0.10.0/disk0 which again would then get aliased to the actual disk device node behind pci device 0.10.0 (first disk) by SLOF.

> 
> In fact, I don't want Qemu to know anything about our internal nvram
> format. This is a business between the guest FW and the guest OS. The
> only thing qemu is allowed to do is wipe it out if asked to do so :-)

It might be useful to use fdt in nvram to store the permanent boot order. That way QEMU / management tools have the chance to make persistent changes. Everyone around already understands fdt anyways :).

> 
>> Um.. as far as I can tell that's a point in favour of my position.  It
>> makes it impossible for qemu to correctly describe boot sequences
>> using these devices in the terms firmware uses internally.  On the
>> other hand it certainly is possible for qemu to pass bootorder="cd"
>> (or whatever) to the firmware via device tree of fw_cfg and have
>> firmware locally interpret that in tersm of what it knows about
>> available devices.
> 
> This is more/less what happens with -boot today. IE. If you pass "c"
> SLOF looks for a bootable disk (though arguably the algorithm could be
> improved), "d" for a bootable optical media etc...
> 
> We definitely want something a bit more expressive and in some case
> might even be able to pass down from the command line a full path to an
> actual device but we don't necessarily want qemu to understand the nvram
> format of this.
> 
> Make it an expressive representation that makes sense to qemu, and let
> the FW "translate" that to something it understands internally.

Yes :).

Regardless of this problem, I think the conclusion on how to gandle default -boot makes sense to everyone, so you (Avik?) can already start working on that one while we nail down the details of the boot protocol handshakes between QEMU and SLOF.


Alex

Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote:
> 
> 
> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
> > 
> >>>> 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.
> >>> 
> >>> It may not be straight forward, but it's what makes the most sense from
> >>> a user's PoV.
> >> 
> >> Bollocks.  Using -boot to override the normal boot sequence
> >> permanently changing the normal boot sequence absoultely does not make
> >> sense from a user's PoV.
> > 
> > I strongly agree with David here. -boot should not change the persistent
> > state.
> 
> I think Anthony and you are looking at 2 different use cases, each
> with their own sane reasoning.
> 
> You want to have the chance to override the boot order temporarily
> for things like cd boot or quick guest rescue missions.
> 
> You also want to be able to permanently change the guest's boot
> order from a management tool. At that same place you want to be able
> to display it, so you don't have to boot your vm to know what it
> would be doing.

That's true to an extent.  However, I vehemently disagree that it's
arbitrary which one gets the new option.  Neither -boot nor bootindex=
alter any persistent data now and they should not suddenly start doing
so.

Now a method of externally altering the firmware persistent boot order
would certainly be nice to have.  However, I'm not at all convinced
that it's realistically possible to do that in way that has a platform
neutral interface.  The fundamental problem here is that we're tied to
the pre-existing ways the platform stores the boot order information
and what that's even capable of expressing can be very different from
platform to platform: can it express an arbitrary list, or just a
limited number of devices, or just one?  can it represent arbitrary
devices in some firmware id/address scheme, or does it just
give order of a fixed set of known devices?  or is it even more
limited, containing just a few "CD before disk" type booleans?  for
that matter, does the firmware even have any notion at all of a
persistent configurable boot order?

If the configuration tool/setting has to be platform specific anyway,
then most of the questions the current proposal attempts to address
simply don't arise.  We could make such a tool for pseries right now:
access the persistent nvram image via qemu-nbd and poke the necessary
things in.

> As for device detection logic, both face the same problems. You need
> to be able to say 'boot from cd-rom first temporarily' just the same
> as you need to be able to say 'boot from the first cd-rom as first
> boot option permanently'. The permanent change needs to be possible
> with the vm turned off though.
> 
> I suppose that Anthony's reasoning is that we can implement
> temporary in the management layer (or even qemu) if we have the
> permanent mechanism, by switching back to the previous state after
> shutdown if the guest written boot order didn't change.

That really doesn't work, for the reason you mention in the next
paragraph, amongst others.

> I don't mind personally if we have one interface for temporary and
> persistent or 2 separate ones, but I think we should aim for having
> both options available in the long run. Though doing permanent
> changes first and reverting them later could raise problems when you
> kill your vm, since that wouldn't clean up the temporary change.

Not to mention that the persistent store could be used for other
things as well, and restoring it could clobber other changes that the
guest has made and which should be persistent.

> > In our case, the persistent state will have been carefully crafted by
> > complicated scripts by the distro installer, and while I may want to use
> > -boot to boot once off a cd image or similar, I certainly don't want
> > that to affect my nvram setting pointing to the right on-disk
> > bootloader.
> > 
> > Additionally I don't want qemu to have to understand all the intricacies
> > of expressing OFW boot path if we can avoid it.
> 
> Yes, the same problem as EFI for example is facing. The solution here is as simple as it gets: a new device name space. Instead of having a boot list entry saying 'boot from device x, part y, file z' you would get an entry saying 'boot from /qemu/disk0' and leave the rest to the firmware. The good thing about this approach is that it again is persistable and can be used in boot order lists. So you can directly translate -boot cd into /qemu/disk0,/qemu/cdrom. And if you screwed up your guest boot config, just put that order in by hand into permanent config.
> 
> > 
> > Qemu gives as much info as it can and let the firmware itself inside the
> > guest figure things out.
> 
> Yes, that's the only chance we have really. Even for bootindex, which could for example get translated to /qemu/pci/0.10.0/disk0 which again would then get aliased to the actual disk device node behind pci device 0.10.0 (first disk) by SLOF.
> 
> > 
> > In fact, I don't want Qemu to know anything about our internal nvram
> > format. This is a business between the guest FW and the guest OS. The
> > only thing qemu is allowed to do is wipe it out if asked to do so :-)
> 
> It might be useful to use fdt in nvram to store the permanent boot order. That way QEMU / management tools have the chance to make persistent changes. Everyone around already understands fdt anyways :).
> 
> >> Um.. as far as I can tell that's a point in favour of my position.  It
> >> makes it impossible for qemu to correctly describe boot sequences
> >> using these devices in the terms firmware uses internally.  On the
> >> other hand it certainly is possible for qemu to pass bootorder="cd"
> >> (or whatever) to the firmware via device tree of fw_cfg and have
> >> firmware locally interpret that in tersm of what it knows about
> >> available devices.
> > 
> > This is more/less what happens with -boot today. IE. If you pass "c"
> > SLOF looks for a bootable disk (though arguably the algorithm could be
> > improved), "d" for a bootable optical media etc...
> > 
> > We definitely want something a bit more expressive and in some case
> > might even be able to pass down from the command line a full path to an
> > actual device but we don't necessarily want qemu to understand the nvram
> > format of this.
> > 
> > Make it an expressive representation that makes sense to qemu, and let
> > the FW "translate" that to something it understands internally.
> 
> Yes :).
> 
> Regardless of this problem, I think the conclusion on how to gandle default -boot makes sense to everyone, so you (Avik?) can already start working on that one while we nail down the details of the boot protocol handshakes between QEMU and SLOF.
> 
> 
> Alex
> 

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

Re: [Qemu-devel] nvram and boot order

[Alexander Graf]

On 19.10.2012, at 10:24, David Gibson <dwg@au1.ibm.com> wrote:

> On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote:
>> 
>> 
>> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>> 
>>> On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
>>> 
>>>>>> 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.
>>>>> 
>>>>> It may not be straight forward, but it's what makes the most sense from
>>>>> a user's PoV.
>>>> 
>>>> Bollocks.  Using -boot to override the normal boot sequence
>>>> permanently changing the normal boot sequence absoultely does not make
>>>> sense from a user's PoV.
>>> 
>>> I strongly agree with David here. -boot should not change the persistent
>>> state.
>> 
>> I think Anthony and you are looking at 2 different use cases, each
>> with their own sane reasoning.
>> 
>> You want to have the chance to override the boot order temporarily
>> for things like cd boot or quick guest rescue missions.
>> 
>> You also want to be able to permanently change the guest's boot
>> order from a management tool. At that same place you want to be able
>> to display it, so you don't have to boot your vm to know what it
>> would be doing.
> 
> That's true to an extent.  However, I vehemently disagree that it's
> arbitrary which one gets the new option.  Neither -boot nor bootindex=
> alter any persistent data now and they should not suddenly start doing
> so.
> 
> Now a method of externally altering the firmware persistent boot order
> would certainly be nice to have.  However, I'm not at all convinced
> that it's realistically possible to do that in way that has a platform
> neutral interface.  The fundamental problem here is that we're tied to
> the pre-existing ways the platform stores the boot order information
> and what that's even capable of expressing can be very different from
> platform to platform: can it express an arbitrary list, or just a
> limited number of devices, or just one?  can it represent arbitrary
> devices in some firmware id/address scheme, or does it just
> give order of a fixed set of known devices?  or is it even more
> limited, containing just a few "CD before disk" type booleans?  for
> that matter, does the firmware even have any notion at all of a
> persistent configurable boot order?

You get 2 lists from machine specific code:

  - potentially available boot devices
  - current boot order list

Both lists contain a number of stringsy the mapping of those strings to platform specific data is responsibility of the platform. After all, the platform gave us the list of available devices, so it better accepts them in the boot order list.

Then you basically have to query the machine (with full device state populated, otherwise the available list isn't available) for the list of devices you're able to boot from. You also ask it for its current boot ordered list. An external tool can display both and alles you to add/remove entries from the current list and reshuffle them.

When you boot the VM you now habe to tell it to actually use that new boot order. This can hapen in 2 possible ways:

  - write it to a special section that is declared as temporary, taking precedence over the internal boot order
  - same as above, but with a flag indicating to SLOF that we want to persist it

Whether this information is passed through a special section in nvram or through fdt is an implementation detail to me. Nvram has the benefit of isolated commands you can execute:

  $ qemu -change-boot-order foo,bar
  <time passes>
  $ qemu

Would give you a VMwith the setzings you changed, while

  $ virsh change boot order foo,bar
  <time passes>
  $ qemu -override-boot-order foo,bar

Means management tools need to remember the boot order in internal state.

> 
> If the configuration tool/setting has to be platform specific anyway,
> then most of the questions the current proposal attempts to address
> simply don't arise.  We could make such a tool for pseries right now:
> access the persistent nvram image via qemu-nbd and poke the necessary
> things in.

we want to expose the same interface to the layers above.

Alex

> 
>> As for device detection logic, both face the same problems. You need
>> to be able to say 'boot from cd-rom first temporarily' just the same
>> as you need to be able to say 'boot from the first cd-rom as first
>> boot option permanently'. The permanent change needs to be possible
>> with the vm turned off though.
>> 
>> I suppose that Anthony's reasoning is that we can implement
>> temporary in the management layer (or even qemu) if we have the
>> permanent mechanism, by switching back to the previous state after
>> shutdown if the guest written boot order didn't change.
> 
> That really doesn't work, for the reason you mention in the next
> paragraph, amongst others.
> 
>> I don't mind personally if we have one interface for temporary and
>> persistent or 2 separate ones, but I think we should aim for having
>> both options available in the long run. Though doing permanent
>> changes first and reverting them later could raise problems when you
>> kill your vm, since that wouldn't clean up the temporary change.
> 
> Not to mention that the persistent store could be used for other
> things as well, and restoring it could clobber other changes that the
> guest has made and which should be persistent.
> 
>>> In our case, the persistent state will have been carefully crafted by
>>> complicated scripts by the distro installer, and while I may want to use
>>> -boot to boot once off a cd image or similar, I certainly don't want
>>> that to affect my nvram setting pointing to the right on-disk
>>> bootloader.
>>> 
>>> Additionally I don't want qemu to have to understand all the intricacies
>>> of expressing OFW boot path if we can avoid it.
>> 
>> Yes, the same problem as EFI for example is facing. The solution here is as simple as it gets: a new device name space. Instead of having a boot list entry saying 'boot from device x, part y, file z' you would get an entry saying 'boot from /qemu/disk0' and leave the rest to the firmware. The good thing about this approach is that it again is persistable and can be used in boot order lists. So you can directly translate -boot cd into /qemu/disk0,/qemu/cdrom. And if you screwed up your guest boot config, just put that order in by hand into permanent config.
>> 
>>> 
>>> Qemu gives as much info as it can and let the firmware itself inside the
>>> guest figure things out.
>> 
>> Yes, that's the only chance we have really. Even for bootindex, which could for example get translated to /qemu/pci/0.10.0/disk0 which again would then get aliased to the actual disk device node behind pci device 0.10.0 (first disk) by SLOF.
>> 
>>> 
>>> In fact, I don't want Qemu to know anything about our internal nvram
>>> format. This is a business between the guest FW and the guest OS. The
>>> only thing qemu is allowed to do is wipe it out if asked to do so :-)
>> 
>> It might be useful to use fdt in nvram to store the permanent boot order. That way QEMU / management tools have the chance to make persistent changes. Everyone around already understands fdt anyways :).
>> 
>>>> Um.. as far as I can tell that's a point in favour of my position.  It
>>>> makes it impossible for qemu to correctly describe boot sequences
>>>> using these devices in the terms firmware uses internally.  On the
>>>> other hand it certainly is possible for qemu to pass bootorder="cd"
>>>> (or whatever) to the firmware via device tree of fw_cfg and have
>>>> firmware locally interpret that in tersm of what it knows about
>>>> available devices.
>>> 
>>> This is more/less what happens with -boot today. IE. If you pass "c"
>>> SLOF looks for a bootable disk (though arguably the algorithm could be
>>> improved), "d" for a bootable optical media etc...
>>> 
>>> We definitely want something a bit more expressive and in some case
>>> might even be able to pass down from the command line a full path to an
>>> actual device but we don't necessarily want qemu to understand the nvram
>>> format of this.
>>> 
>>> Make it an expressive representation that makes sense to qemu, and let
>>> the FW "translate" that to something it understands internally.
>> 
>> Yes :).
>> 
>> Regardless of this problem, I think the conclusion on how to gandle default -boot makes sense to everyone, so you (Avik?) can already start working on that one while we nail down the details of the boot protocol handshakes between QEMU and SLOF.
>> 
>> 
>> Alex
>> 
> 
> -- 
> 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
> 

Re: [Qemu-devel] nvram and boot order

[Anthony Liguori]

David Gibson <dwg@au1.ibm.com> writes:

> On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote:
>> 
>> 
>> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>> 
>> > On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
>> > 
>> >>>> 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.
>> >>> 
>> >>> It may not be straight forward, but it's what makes the most sense from
>> >>> a user's PoV.
>> >> 
>> >> Bollocks.  Using -boot to override the normal boot sequence
>> >> permanently changing the normal boot sequence absoultely does not make
>> >> sense from a user's PoV.
>> > 
>> > I strongly agree with David here. -boot should not change the persistent
>> > state.
>> 
>> I think Anthony and you are looking at 2 different use cases, each
>> with their own sane reasoning.
>> 
>> You want to have the chance to override the boot order temporarily
>> for things like cd boot or quick guest rescue missions.
>> 
>> You also want to be able to permanently change the guest's boot
>> order from a management tool. At that same place you want to be able
>> to display it, so you don't have to boot your vm to know what it
>> would be doing.
>
> That's true to an extent.  However, I vehemently disagree that it's
> arbitrary which one gets the new option.  Neither -boot nor bootindex=
> alter any persistent data now and they should not suddenly start doing
> so.

That's not true.

For the PC, -boot modifies the CMOS memory.  If we persisted CMOS, then
-boot would cause a persistent modification in the boot order.

Regards,

Anthony Liguori

Re: [Qemu-devel] nvram and boot order

[Peter Maydell]

On 19 October 2012 15:21, Anthony Liguori <aliguori@us.ibm.com> wrote:
> David Gibson <dwg@au1.ibm.com> writes:
>> That's true to an extent.  However, I vehemently disagree that it's
>> arbitrary which one gets the new option.  Neither -boot nor bootindex=
>> alter any persistent data now and they should not suddenly start doing
>> so.
>
> That's not true.
>
> For the PC, -boot modifies the CMOS memory.  If we persisted CMOS, then
> -boot would cause a persistent modification in the boot order.

That would be a bug you'd need to fix if we persisted CMOS :-)

-- PMM

Re: [Qemu-devel] nvram and boot order

[Blue Swirl]

On Thu, Oct 18, 2012 at 6:32 AM, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
>>
>>>>> 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.
>>>>
>>>> It may not be straight forward, but it's what makes the most sense from
>>>> a user's PoV.
>>>
>>> Bollocks.  Using -boot to override the normal boot sequence
>>> permanently changing the normal boot sequence absoultely does not make
>>> sense from a user's PoV.
>>
>> I strongly agree with David here. -boot should not change the persistent
>> state.
>
> I think Anthony and you are looking at 2 different use cases, each with their own sane reasoning.
>
> You want to have the chance to override the boot order temporarily for things like cd boot or quick guest rescue missions.
>
> You also want to be able to permanently change the guest's boot order from a management tool. At that same place you want to be able to display it, so you don't have to boot your vm to know what it would be doing.
>
> As for device detection logic, both face the same problems. You need to be able to say 'boot from cd-rom first temporarily' just the same as you need to be able to say 'boot from the first cd-rom as first boot option permanently'. The permanent change needs to be possible with the vm turned off though.
>
> I suppose that Anthony's reasoning is that we can implement temporary in the management layer (or even qemu) if we have the permanent mechanism, by switching back to the previous state after shutdown if the guest written boot order didn't change.
>
> I don't mind personally if we have one interface for temporary and persistent or 2 separate ones, but I think we should aim for having both options available in the long run. Though doing permanent changes first and reverting them later could raise problems when you kill your vm, since that wouldn't clean up the temporary change.
>
>>
>> In our case, the persistent state will have been carefully crafted by
>> complicated scripts by the distro installer, and while I may want to use
>> -boot to boot once off a cd image or similar, I certainly don't want
>> that to affect my nvram setting pointing to the right on-disk
>> bootloader.
>>
>> Additionally I don't want qemu to have to understand all the intricacies
>> of expressing OFW boot path if we can avoid it.
>
> Yes, the same problem as EFI for example is facing. The solution here is as simple as it gets: a new device name space. Instead of having a boot list entry saying 'boot from device x, part y, file z' you would get an entry saying 'boot from /qemu/disk0' and leave the rest to the firmware. The good thing about this approach is that it again is persistable and can be used in boot order lists. So you can directly translate -boot cd into /qemu/disk0,/qemu/cdrom. And if you screwed up your guest boot config, just put that order in by hand into permanent config.

For comparison, QEMU passes boot device flag (c/d) to OpenBIOS, which
translates it to either first disk or cdrom. Then we have -prom-env
which can be used to pass further paths (/iommu/sbus/esp/sd@0,0:/unix)
but this is controlled by user. OpenBIOS does not understand bootindex
yet, neither QEMU can't generate useful paths at least for Sparc32. So
far I have been thinking that bootindex would equal OFW boot path, but
why would that not work?

>
>>
>> Qemu gives as much info as it can and let the firmware itself inside the
>> guest figure things out.
>
> Yes, that's the only chance we have really. Even for bootindex, which could for example get translated to /qemu/pci/0.10.0/disk0 which again would then get aliased to the actual disk device node behind pci device 0.10.0 (first disk) by SLOF.
>
>>
>> In fact, I don't want Qemu to know anything about our internal nvram
>> format. This is a business between the guest FW and the guest OS. The
>> only thing qemu is allowed to do is wipe it out if asked to do so :-)
>
> It might be useful to use fdt in nvram to store the permanent boot order. That way QEMU / management tools have the chance to make persistent changes. Everyone around already understands fdt anyways :).
>
>>
>>> Um.. as far as I can tell that's a point in favour of my position.  It
>>> makes it impossible for qemu to correctly describe boot sequences
>>> using these devices in the terms firmware uses internally.  On the
>>> other hand it certainly is possible for qemu to pass bootorder="cd"
>>> (or whatever) to the firmware via device tree of fw_cfg and have
>>> firmware locally interpret that in tersm of what it knows about
>>> available devices.
>>
>> This is more/less what happens with -boot today. IE. If you pass "c"
>> SLOF looks for a bootable disk (though arguably the algorithm could be
>> improved), "d" for a bootable optical media etc...
>>
>> We definitely want something a bit more expressive and in some case
>> might even be able to pass down from the command line a full path to an
>> actual device but we don't necessarily want qemu to understand the nvram
>> format of this.
>>
>> Make it an expressive representation that makes sense to qemu, and let
>> the FW "translate" that to something it understands internally.
>
> Yes :).
>
> Regardless of this problem, I think the conclusion on how to gandle default -boot makes sense to everyone, so you (Avik?) can already start working on that one while we nail down the details of the boot protocol handshakes between QEMU and SLOF.
>
>
> Alex
>
>

Re: [Qemu-devel] nvram and boot order

[Benjamin Herrenschmidt]

On Fri, 2012-10-19 at 09:21 -0500, Anthony Liguori wrote:

> > That's true to an extent.  However, I vehemently disagree that it's
> > arbitrary which one gets the new option.  Neither -boot nor bootindex=
> > alter any persistent data now and they should not suddenly start doing
> > so.
> 
> That's not true.
> 
> For the PC, -boot modifies the CMOS memory.  If we persisted CMOS, then
> -boot would cause a persistent modification in the boot order.

Come on Anthony, you are talking like a politician now :-) "If we
were...". The fact is that from a user perspective today, the effect is
not persistent. Thus making it so would be a chance in perceived
behaviour. Not a big deal but I think your "correction" of David
statement was unnecessary :-)

As a matter of fact, I would even argue that if you make the CMOS
persistent on x86, you should change the effect of -boot to write to a
part of that CMOS that is "for the next boot only" in order to preserve
the user perceived (and probably expected behaviour).

In any case, I think we have an agreement that we want both methods.

What I think David explained fairly well and I share his opinion here is
that it's fairly easy and probably higher on the priority list, to
provide the methods to do things in a volatile way. So let's do that
now, which is going to be in line with the current perceived behaviour
and generally makes sense.

We can *also* look at putting together a mechanism for setting the boot
device permanently. But that's non trivial for several reasons and so we
shouldn't gate the first one which is immediately useful because we are
still debating the second one.

Cheers,
Ben.

Re: [Qemu-devel] nvram and boot order

[David Gibson]

On Fri, Oct 19, 2012 at 10:40:45AM +0200, Alexander Graf wrote:
> 
> 
> On 19.10.2012, at 10:24, David Gibson <dwg@au1.ibm.com> wrote:
> 
> > On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote:
> >> 
> >> 
> >> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >> 
> >>> On Thu, 2012-10-18 at 11:09 +1100, David Gibson wrote:
> >>> 
> >>>>>> 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.
> >>>>> 
> >>>>> It may not be straight forward, but it's what makes the most sense from
> >>>>> a user's PoV.
> >>>> 
> >>>> Bollocks.  Using -boot to override the normal boot sequence
> >>>> permanently changing the normal boot sequence absoultely does not make
> >>>> sense from a user's PoV.
> >>> 
> >>> I strongly agree with David here. -boot should not change the persistent
> >>> state.
> >> 
> >> I think Anthony and you are looking at 2 different use cases, each
> >> with their own sane reasoning.
> >> 
> >> You want to have the chance to override the boot order temporarily
> >> for things like cd boot or quick guest rescue missions.
> >> 
> >> You also want to be able to permanently change the guest's boot
> >> order from a management tool. At that same place you want to be able
> >> to display it, so you don't have to boot your vm to know what it
> >> would be doing.
> > 
> > That's true to an extent.  However, I vehemently disagree that it's
> > arbitrary which one gets the new option.  Neither -boot nor bootindex=
> > alter any persistent data now and they should not suddenly start doing
> > so.
> > 
> > Now a method of externally altering the firmware persistent boot order
> > would certainly be nice to have.  However, I'm not at all convinced
> > that it's realistically possible to do that in way that has a platform
> > neutral interface.  The fundamental problem here is that we're tied to
> > the pre-existing ways the platform stores the boot order information
> > and what that's even capable of expressing can be very different from
> > platform to platform: can it express an arbitrary list, or just a
> > limited number of devices, or just one?  can it represent arbitrary
> > devices in some firmware id/address scheme, or does it just
> > give order of a fixed set of known devices?  or is it even more
> > limited, containing just a few "CD before disk" type booleans?  for
> > that matter, does the firmware even have any notion at all of a
> > persistent configurable boot order?
> 
> You get 2 lists from machine specific code:
> 
>   - potentially available boot devices
>   - current boot order list
> 
> Both lists contain a number of stringsy the mapping of those strings
> to platform specific data is responsibility of the platform. After
> all, the platform gave us the list of available devices, so it
> better accepts them in the boot order list.

Um... I'm having a lot of trouble parsing this.  What is the "You"
here, and what are you counting as the "platform".

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

Re: [Qemu-devel] nvram and boot order

[David Gibson]

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