From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THBEU-0006TX-2h for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:22:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THBEK-0006W9-KV for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:22:13 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:56145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THBEG-0006Tz-3D for qemu-devel@nongnu.org; Thu, 27 Sep 2012 06:22:04 -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, 27 Sep 2012 20:19:48 +1000 Message-ID: <1348741303.24701.29.camel@pasglop> From: Benjamin Herrenschmidt Date: Thu, 27 Sep 2012 20:21:43 +1000 In-Reply-To: <20120927095136.GI23096@redhat.com> References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 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: Gleb Natapov Cc: qemu-devel qemu-devel , "qemu-ppc@nongnu.org List" , Alexander Graf , Nikunj A Dadhania , Avik Sil 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. 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. > 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.