qemu-ppc
[Top][All Lists]
Advanced

[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: Alexander Graf
Subject: Re: [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting
Date: Fri, 5 Oct 2012 02:43:31 +0200

On 05.10.2012, at 02:34, David Gibson 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"
> 
> Ok, so I've just started looking at the bootindex stuff.  What
> function is generating these strings?
> 
> We should also be able to get the raw bootindex values for a qdev,
> yes?  I was thinking we could instead copy those values into the
> device tree when we populate it.  The trouble is that we don't
> actually generate (in qemu) nodes for individual disks under a vscsi,
> or for individual PCI devices under the host bridge (that's done by
> SLOF).  Still thinking...

Well. You can track it down to the device level and you know the drive index. 
Maybe you could be clever if you had a device property that contains the drive 
index and boot index to it?

> 
> An aside, I'm thinking that once we do get bootindex working, then
> boot devices specified in NVRAM should have priority below all devices
> with explicit supplied bootindex, but above any that don't.  Does that
> seem right to you?

Yes, that sounds exactly right :).

> 
>> 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, personally, I think this is quite a reasonable interim measure
> until we figure out how to do bootindex.  I will fold it into our
> internal tree for now, even if the qemu people are going to bitch and
> moan about its imperfections.  Can you send me a clean copy with
> commit message, please?

I actually don't remember having seen a patch at all :).


Alex




reply via email to

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