From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THB5p-0003AA-W0 for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:13:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THB5j-0003Tm-UV for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:13:17 -0400 Date: Thu, 27 Sep 2012 12:13:05 +0200 From: Gleb Natapov Message-ID: <20120927101305.GL23096@redhat.com> References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> <87fw63hjb2.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fw63hjb2.fsf@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania Cc: qemu-devel qemu-devel , Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , Alexander Graf , Avik Sil On Thu, Sep 27, 2012 at 03:35:53PM +0530, Nikunj A Dadhania wrote: > On Thu, 27 Sep 2012 11:51:36 +0200, Gleb Natapov wrote: > > On Thu, Sep 27, 2012 at 11:33:31AM +0200, Alexander Graf wrote: > > > > > > On 27.09.2012, at 11:29, Benjamin Herrenschmidt wrote: > > > > > > > On Thu, 2012-09-27 at 14:51 +0530, Avik Sil wrote: > > > >> Hi, > > > >> > > > >> We would like to get a method to boot from devices provided in -boot > > > >> arguments in qemu when the 'boot-device' is set in nvram for pseries > > > >> machine. I mean the boot device specified in -boot should get a > > > >> precedence over the 'boot-device' specified in nvram. > > > >> > > > >> At the same time, when -boot is not provided, i.e., the default boot > > > >> order "cad" is present, the device specified in nvram 'boot-device' > > > >> should get precedence if it is set. > > > >> > > > >> What should be the elegant way to implement this requirement? > > > >> Suggestions welcome. > > > > > > > > Actually I think it's a more open question. We have essentially two > > > > things at play here: > > > > > > > > - With the new nvram model, the firmware can store a boot device > > > > reference in it, which is standard OF practice, and in fact the various > > > > distro installers are going to do just that > > > > > > > > - Qemu has its own boot order thingy via -boot, which we loosely > > > > translate as c = first bootable disk we find (actually first disk we > > > > find, we should probably make the algorithm a bit smarter), d = first > > > > cdrom we find, n = network , ... We pass that selection (boot list) down > > > > to SLOF via a device-tree property. > > > > > > > > The question is thus what precedence should we give them. I was > > > > initially thinking that an explicit qemu boot list should override the > > > > firmware nvram setting but I'm now not that sure anymore. > > > > > > > > The -boot list is at best a "blurry" indication of what type of device > > > > the user wants ... The firmware setting in nvram is precise. > > > > > > IIRC gleb had implemented a specific boot order thing. Gleb, mind to enlighten us? :) > > > > > Yes, forget about -boot. It is deprecated :) You should use bootindex > > (device property) to set boot priority. It constructs OF device path > > and passes it to firmware. > > If the user does not set bootindex, qemu would decide the bootindex? > No. Firmware decides. QEMU just tells to firmware that it does not have bootindex. > If it does, there will be a default bootindex. Then the problem still > remains, qemu decided the boot-order, in which case we would want to > pick the nvram based setting. This is again difficult to distinguish. > > > There is nothing "blurry" about OF device > > path. The problem is that it works reasonably well with legacy BIOS > > since it is enough to specify device to boot from, but with EFI (OF is > > the same I guess) it is not enough to point to a device to boot from, > > but you also need to specify a file you want to boot and this is where > > bootindex approach fails. > > By file I suppose you mean OF device-path. > No. By file I mean a file on dedicated EFI FAT partition that EFI loads during boot. I do not know if OF has something similar. > > > > > > I think the command line should override anything user specified. So basically: > > > > > > * user defined -boot option (or bootindex magic from Gleb) > > > * nvram > > > * fallback to default > > > > > Regards > Nikunj -- Gleb.