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

[Benjamin Herrenschmidt]

On Thu, 2012-09-27 at 11:29 +0200, Alexander Graf wrote:

> I would like to see us reuse the same methods that all the other
> platforms are using (x86, OpenBIOS PPC, etc). On these machines we
> have fw_cfg which can tell firmware configuration bits that the
> hypervisor can pass in.
> 
> However, using MMIO might be a bad idea for that one, since 970 HV KVM
> can not handle that. So how about adding a hypercall based fw_cfg
> interface in parallel to the current MMIO/PIO based one?
> 
> That way we could reuse almost all of the existing infrastructure.

Hey Alex, stop smoking bad stuff :-)

The question has nothing to do with the communication method and we are
certainly not going to biggy back the fw_cfg junk on top of our existing
device-tree.

We already have a mechanism to pass the qemu -boot argument down to
SLOF, its been there for ever and it works today to select the default
boot device, but it's imprecise. See my other email. The mechanism is
via device-tree properties and that isn't going to change.

The questions are about precedence, algorithm to apply for the actual
selection between -boot arguments and guest nvram OFW boot-device
setting, and to some extent about the ability to know whether an
existing -boot list was passed at all vs. defaulting to the nvram
setting.

Cheers,
Ben.