On Fri, Oct 05, 2012 at 02:43:31AM +0200, Alexander Graf wrote:
>
> 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/channel@0/disk@0,1
> >> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,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?
Yeah, I guess. Working that out is a lot more complex than cases
where we have a one-to-one correspondance between qdevs and device
tree nodes.
> > 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 :).
Um.. it was immediately below that in the original message.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
