From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRGAi-0007W0-Dx for qemu-devel@nongnu.org; Thu, 25 Oct 2012 01:40:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRGAg-0006XO-JU for qemu-devel@nongnu.org; Thu, 25 Oct 2012 01:40:00 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:46456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRGAg-0006X4-1O for qemu-devel@nongnu.org; Thu, 25 Oct 2012 01:39:58 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 25 Oct 2012 15:37:05 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9P5Tnv742401820 for ; Thu, 25 Oct 2012 16:29:50 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9P5dlVu019345 for ; Thu, 25 Oct 2012 16:39:48 +1100 Date: Thu, 25 Oct 2012 15:14:07 +1100 From: David Gibson Message-ID: <20121025041407.GE7222@truffula.fritz.box> References: <87wqyqyyxi.fsf@codemonkey.ws> <20121017005852.GY4640@truffula.fritz.box> <87vce9t13b.fsf@codemonkey.ws> <20121018000911.GE30304@truffula.fritz.box> <1350523098.4678.133.camel@pasglop> <9431E4A3-571E-4655-9B6C-23D3900EDF07@suse.de> <20121019082452.GW23523@truffula.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] nvram and boot order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , "qemu-devel@nongnu.org" , Avik Sil On Fri, Oct 19, 2012 at 10:40:45AM +0200, Alexander Graf wrote: > > > On 19.10.2012, at 10:24, David Gibson wrote: > > > On Thu, Oct 18, 2012 at 08:32:54AM +0200, Alexander Graf wrote: > >> > >> > >> On 18.10.2012, at 03:18, Benjamin Herrenschmidt 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