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

[Thomas Huth]

On 02.02.2017 01:06, Alexey Kardashevskiy wrote:
> 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

Actually, that string "3d-controller" is generated by SLOF, not by QEMU!
Putting the device into a "group" and adding a proper name is currently
completely done by SLOF, see slof/fs/pci-class-code-names.fs for example.
I've now also had a closer look at the QEMU side, and it will be quite
hard to implement this there, too, since there is no easy way to always
"categorize" a device there, as far as I can see. There are the
DEVICE_CATEGORY_STORAGE and DEVICE_CATEGORY_NETWORK category bits, but
they won't be set for pass-through devices. And you'd also need some
additional logic there to distinguish between normal hard disk and cdrom
storage devices...
So I think we should really rather implement this on the SLOF side
instead. Could you please reconsider my patch? Or do you see a feasible
way to implement this on the QEMU side for passthrough devices, too?

 Thomas