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

[Alexey Kardashevskiy]

On 15/02/17 22:26, Thomas Huth wrote:
> 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.

spapr_create_pci_child_dt() could be smarter and look at the PCI device
class (spapr_populate_pci_child_dt() reads it anyway) and use instead it of
pci@%x,%x. Classes are defined in include/hw/pci/pci_ids.h ,
PCI_CLASS_XXXX. We already populate the tree in QEMU (even assign
addresses), only node names are left nalf-cooked really...


> 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...

It is already in QEMU which has better knowledge about disk vs. cdrom -
QOM-cast to "scsi-cd"/"scsi-disk".

> 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?

I still do not see any blocker against doing this in QEMU. Most devices
support "bootindex" which we already handle via "qemu,boot-list", for
non-straightforward cases we have a machine-specific spapr_get_fw_dev_path().


-- 
Alexey