From patchwork Thu Oct 4 10:55:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Avik Sil X-Patchwork-Id: 189262 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AD2912C03DA for ; Fri, 5 Oct 2012 05:42:08 +1000 (EST) Received: from localhost ([::1]:47852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJpd5-00054T-6F for incoming@patchwork.ozlabs.org; Thu, 04 Oct 2012 13:54:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJj5n-0007KW-8J for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:55:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJj5g-0005y6-PB for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:55:46 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:35634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJj5g-0005vL-0R for qemu-devel@nongnu.org; Thu, 04 Oct 2012 06:55:40 -0400 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Oct 2012 20:53:00 +1000 Received: from d23relay04.au.ibm.com (202.81.31.246) by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 4 Oct 2012 20:52:58 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q94AjvKo28508272; Thu, 4 Oct 2012 20:45:58 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q94AtUex031208; Thu, 4 Oct 2012 20:55:30 +1000 Received: from [9.124.35.222] (aviksil-thinkpad.in.ibm.com [9.124.35.222]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q94AtSdS031171; Thu, 4 Oct 2012 20:55:29 +1000 Message-ID: <506D6B20.7020508@linux.vnet.ibm.com> Date: Thu, 04 Oct 2012 16:25:28 +0530 From: Avik Sil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gleb Natapov References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> In-Reply-To: <20120927095136.GI23096@redhat.com> x-cbid: 12100410-3568-0000-0000-0000028D52A5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 202.81.31.142 X-Mailman-Approved-At: Thu, 04 Oct 2012 13:54:20 -0400 Cc: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , Alexander Graf , Nikunj A Dadhania , qemu-devel qemu-devel Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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(). Comments welcome. >>> However if we make the nvram override qemu, then it's trickier to >>> force-boot from, let's say, a rescue CD. The user would have to stop the >>> SLOF boot process by pressing a key then manually type something like >>> "boot cdrom". >>> >>> Maybe the right approach is "in between", and is that the primary driver >>> is the -boot argument. For each entry in the boot list, if it's "c", use >>> the configured boot-device or fallback to the automatic guess SLOF tries >>> to do today in absence of a boot-device. If it's "d" or "n" force it >>> respectively to cdrom or network... >>> >>> I think there is no perfect solution here. What do you guys think is the >>> less user unfriendly ? >> >> 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 >> >>> Eventually we should try to implement some sort of interactive boot >>> device selection in SLOF, such as SMS does on pseries, but that will >>> take a bit of time. >> >> That would be en par with the bootmenu on x86 :). Please check out how x86 models these things. It could sure be interesting for pseries. >> >> >> Alex > > -- > Gleb. > > Regards, Avik diff --git a/hw/spapr.c b/hw/spapr.c index e6bf522..673bcc8 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -284,7 +284,8 @@ static void *spapr_create_fdt_skel(const char *cpu_model, _FDT((fdt_property(fdt, "qemu,boot-kernel", &kprop, sizeof(kprop)))); } - _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device))); + if (!default_boot_order) + _FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device))); _FDT((fdt_property_cell(fdt, "qemu,graphic-width", graphic_width))); _FDT((fdt_property_cell(fdt, "qemu,graphic-height", graphic_height))); _FDT((fdt_property_cell(fdt, "qemu,graphic-depth", graphic_depth))); diff --git a/sysemu.h b/sysemu.h index 65552ac..f0822b4 100644 --- a/sysemu.h +++ b/sysemu.h @@ -129,6 +129,7 @@ extern int no_shutdown; extern int semihosting_enabled; extern int old_param; extern int boot_menu; +extern int default_boot_order; extern uint8_t *boot_splash_filedata; extern int boot_splash_filedata_size; extern uint8_t qemu_extra_params_fw[2]; diff --git a/vl.c b/vl.c index 48049ef..bf369e6 100644 --- a/vl.c +++ b/vl.c @@ -230,6 +230,7 @@ int ctrl_grab = 0; unsigned int nb_prom_envs = 0; const char *prom_envs[MAX_PROM_ENVS]; int boot_menu; +int default_boot_order = 1; uint8_t *boot_splash_filedata; int boot_splash_filedata_size; uint8_t qemu_extra_params_fw[2]; @@ -2668,6 +2669,7 @@ int main(int argc, char **argv, char **envp) qemu_opts_parse(qemu_find_opts("boot-opts"), optarg, 0); } + default_boot_order = 0; } break; case QEMU_OPTION_fda: