From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJjcb-0006UL-0e for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:29:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJjcW-0000xg-P3 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:29:40 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:54622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJjcW-0000xP-4p for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:29:36 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Oct 2012 16:59:32 +0530 Message-ID: <506D7317.40906@linux.vnet.ibm.com> Date: Thu, 04 Oct 2012 16:59:27 +0530 From: Avik Sil MIME-Version: 1.0 References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> <506D6B20.7020508@linux.vnet.ibm.com> <20121004112217.GA27396@redhat.com> In-Reply-To: <20121004112217.GA27396@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , Alexander Graf , Nikunj A Dadhania , qemu-devel qemu-devel On 10/04/2012 04:52 PM, Gleb Natapov wrote: > On Thu, Oct 04, 2012 at 04:25:28PM +0530, Avik Sil wrote: >> On 09/27/2012 03:21 PM, 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. 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. 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? >>> >> I looked at the bootindex stuff and found that when the bootindex is >> specified for the disk and cdrom it generates a string like: >> >> "/spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,1 >> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,0" >> >> Now converting/translating this to OF device path is going to be >> much trickier and might not be proper. So I propose a simple >> solution by introducing a global flag that checks if explicit -boot >> parameter is provided or not. The presence of this parameter is >> verified in SLOF firmware. The flag had to be introduced as >> boot_devices defaults to "cad" instead of null and passed to >> machine->init(). >> > So you want to hack around the problem. If -boot is specified what > device are you going to boot from? It is going to boot from the device specified in -boot as default_boot_order is set to 0 in that case. Regards, Avik