[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: |
Benjamin Herrenschmidt |
Subject: |
Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting |
Date: |
Thu, 27 Sep 2012 19:29:10 +1000 |
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.
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 ?
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.
Cheers,
Ben.
- [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Avik Sil, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting,
Benjamin Herrenschmidt <=
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Alexander Graf, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Nikunj A Dadhania, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Nikunj A Dadhania, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/09/27
- Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting, Benjamin Herrenschmidt, 2012/09/27
- Re: [Qemu-ppc] [Qemu-devel] Qemu boot device precedence over nvram boot-device setting, Gleb Natapov, 2012/09/27