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?
> 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 -- Gleb.