From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOU0a-0008BF-0D for qemu-devel@nongnu.org; Wed, 17 Oct 2012 09:50:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOU0U-0005Gl-6l for qemu-devel@nongnu.org; Wed, 17 Oct 2012 09:50:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOU0T-0005Gd-Uy for qemu-devel@nongnu.org; Wed, 17 Oct 2012 09:49:58 -0400 Date: Wed, 17 Oct 2012 15:48:42 +0200 From: Gleb Natapov Message-ID: <20121017134842.GR20788@redhat.com> References: <87wqyqyyxi.fsf@codemonkey.ws> <1350418073.4678.58.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1350418073.4678.58.camel@pasglop> Subject: Re: [Qemu-devel] nvram and boot order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: qemu-devel@nongnu.org, Alex Graf , Anthony Liguori , Avik Sil , David Gibson 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.