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: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting
Date: Thu, 4 Oct 2012 13:30:27 +0200

On 04.10.2012, at 13:29, Avik Sil wrote:

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

Imagine you have 2 controllers:

  * vio
  * virtio

and you specify -boot c. Which device are you going to boot from?


Alex




reply via email to

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