[SLOF] [PATCH] Rework handling of the "qemu, boot-list" property

[Alexey Kardashevskiy]

On 01/02/17 19:16, Thomas Huth wrote:
> On 01.02.2017 04:05, Alexey Kardashevskiy wrote:
>> On 13/01/17 20:55, Thomas Huth wrote:
>>> If the user started QEMU with both, devices that are specified with
>>> a "bootindex=..." parameter and with the parameter "-boot order=..."
>>> (or "-boot once=..."), there are currently two issues in SLOF with
>>> the resulting boot order:
>>>
>>> 1) Everything from "-boot order=..." gets ignored completely as soon as
>>>    one of the other devices has a "bootindex" parameter - even if we
>>>    boot with "strict=off". For example if the user starts QEMU with
>>>    "-device virtio-blk-pci,bootindex=0 -boot order=cn", the NIC has
>>>    not been specified with a "bootindex" and the block device is not
>>>    bootable, SLOF never tries to boot from the network device.
>>>
>>> 2) The "-boot once=..." feature can never be used as soon as one
>>>    device has been specified with a "bootindex" parameter.
>>>
>>> The devices with "bootindex" are passed to SLOF in a sorted list via
>>> the "qemu,boot-list" property, and the value from "-boot order" or
>>> "-boot once" is passed to SLOF directly via the "qemu,boot-device"
>>> property. To fix the problems when a user specified both, we should
>>> rather treat the "qemu,boot-device" property as a group filter for
>>> the "qemu,boot-list", so that we only consider those devices in
>>> "qemu,boot-list" which match the specified classes from the
>>> "qemu,boot-device" property.
>>> Additionally if we're not in strict=on boot mode, we should always
>>> continue to consider all other boot devices and not stop after
>>> processing the devices from "qemu,boot-list".
>>
>> Rather than doing all of this in SLOF, I'd get rid of qemu,boot-device and
>> populate qemu,boot-list in QEMU, have you considered this approach?
> 
> While this sounds very tempting at a first glance (we could write the
> whole mess in C instead), I'm a little bit afraid that we might run into
> problems with passthrough devices later. Imagine that the user passes a
> PCI NIC through to the guest, and starts QEMU with "-boot once=n" ...
> does QEMU check the type of the PCI card in this case, so it could
> correctly put it into the qemu,boot-list ? If yes, it might be feasible
> to do it all in QEMU, otherwise we likely have to continue with creating
> the correct list in SLOF instead.


We already enumerate all devices in QEMU, we know their classes and we
already support "bootindex" on emulated ones (this creates a proper device
tree path which SLOF can boot from), I do not see how vfio-pci is
different. For example, for my NVIDIA K80 I get:

0 > dev /pci at 800000020000000   ok
0 > ls
7e729f98 :  /pci at 800000020000000
7e72c478 :  |-- 3d-controller at 1
7e72cb40 :  +-- usb at 0 ok


Another thing is that the semantics of "-boot" belongs to QEMU, it may
change it one day and it makes sense to keep the boot list population logic
in QEMU.

Having this written on C is just a small benefit :)


-- 
Alexey