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

[Thomas Huth]

On 16.02.2017 05:46, Alexey Kardashevskiy wrote:
> 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".

And what if you pass-through a PCI SCSI host adapter? Do you expect QEMU
to scan the SCSI bus and classify the devices attached to it? I don't
think that we want to have such logic at the QEMU level, too, do we?

 Thomas