[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device settin
From: |
Gleb Natapov |
Subject: |
Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting |
Date: |
Thu, 4 Oct 2012 13:22:17 +0200 |
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/address@hidden/address@hidden,1
> /spapr-vio-bridge/spapr-vscsi/address@hidden/address@hidden,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.
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting,
Gleb Natapov <=
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Alexander Graf, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Alexander Graf, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Alexander Graf, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Nikunj A Dadhania, 2012/10/05
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/10/04
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/10/04