From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPDSl-0008E0-Nm for qemu-devel@nongnu.org; Fri, 19 Oct 2012 10:22:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TPDSe-0005Lu-1n for qemu-devel@nongnu.org; Fri, 19 Oct 2012 10:22:11 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:41868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPDSd-0005Kf-EY for qemu-devel@nongnu.org; Fri, 19 Oct 2012 10:22:03 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Oct 2012 19:51:50 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9JELdSQ17236020 for ; Fri, 19 Oct 2012 19:51:39 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9JJpTTu022998 for ; Sat, 20 Oct 2012 06:51:30 +1100 From: Anthony Liguori In-Reply-To: <20121019082452.GW23523@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> Date: Fri, 19 Oct 2012 09:21:24 -0500 Message-ID: <876266y23f.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] nvram and boot order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Alexander Graf Cc: "qemu-devel@nongnu.org" , Avik Sil David Gibson writes: > 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. 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