qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avik Sil
Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting
Date: Thu, 04 Oct 2012 16:59:27 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/04/2012 04:52 PM, Gleb Natapov wrote:
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?

It is going to boot from the device specified in -boot as default_boot_order is set to 0 in that case.

Regards,
Avik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]