From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THBSo-0002NS-Ch for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:37:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THBSi-0003AT-2v for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:37:02 -0400 Date: Thu, 27 Sep 2012 12:35:00 +0200 From: Gleb Natapov Message-ID: <20120927103500.GM23096@redhat.com> References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> <1348741303.24701.29.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1348741303.24701.29.camel@pasglop> 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: Benjamin Herrenschmidt Cc: Avik Sil , "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel , Nikunj A Dadhania , Alexander Graf On Thu, Sep 27, 2012 at 08:21:43PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2012-09-27 at 11:51 +0200, Gleb Natapov wrote: > > > 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. There is nothing "blurry" about OF device > > path. > > Of course it is ;-) They are perfectly precise down to the device for > which qemu generates the device-tree ... and from there it requires the > firmware and qemu to both agree on how they are constructed, and it > becomes totally unpredictable once things like f-code drivers coming > from adapter ROMs enter the picture. > If QEMU generates OF device path that can't be used by firmware uniquely identify the device this is QEMU bug. You are correct about ROMs though. At least on a PC single ROM can register multiple boot vectors and since QEMU knows nothing about them it can't prioritize between them. It's sad if OF has similar problem. > In fact, we can probably get them right down the the PCI device for PCI > (for which we don't currently construct the device nodes in qemu, but we > can 'guess'). And we can probably get the right unit address for vscsi, > virtio-scsi, etc... but that's about it. What more do you need? > > > 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. If EFI would specify default file to boot from > > firmware could have used it, but EFI specifies it only for removable media > > (what media is not removable this days, especially with virtualization?). > > We can add qemu parameter to specify file to boot, but how users should > > know the name of the file? > > Cheers, > Ben. > > -- Gleb.