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 <address@hidden> wrote:
> 
> > On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote:
> >> 
> >> 
> >> On 18.10.2012, at 03:18, Benjamin Herrenschmidt <address@hidden> 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