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/channel@0/disk@0,1 >>> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,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
