Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting

[Avik Sil <aviksil@linux.vnet.ibm.com>]

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().

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:


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