[libvirt] [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines'

[Marcel Apfelbaum]

On 11/23/2016 07:35 PM, Eduardo Habkost wrote:
> On Wed, Nov 23, 2016 at 06:43:16PM +0200, Marcel Apfelbaum wrote:
>> On 11/22/2016 03:11 AM, Eduardo Habkost wrote:
>>> The Problem
>>> ===========
>>>
>>> Currently management software has no way to find out which device
>>> types can be plugged in a machine, unless the machine is already
>>> initialized.
>>>
>>
>> Hi Eduardo,
>> Thank you for this interesting series. I think this is a problem
>> worth addressing.
>>

[...]

>>>
>>> PCI vs PCIe
>>> -----------
>>>
>>> Machines with PCIe buses will report INTERFACE_PCIE_DEVICE on
>>> supported-device-types.
>>>
>>> Machines with legacy PCI buses will report TYPE_PCI_DEVICE on
>>> supported-device-types.
>>>
>>> The problem with the current approach is that PCIe devices are
>>> TYPE_PCI_DEVICE subclasses. The allows PCI device classes to
>>> indicate they are PCIe-capable, but there's no obvious way to
>>> indicate that a device is PCIe-only. This needs to be addressed
>>> in a future version of this series.
>>>
>>> Suggestions are welcome.
>>
>>
>> As we talked offline, I personally like an interface IPCIType
>> with a field having 3 possible values {pci/pcie/hybrid}
>>
>> To understand how hybrid works we need some rules, like
>> "pci on pci bus/pcie on pcie bus"
>> "pcie on a non-root pcie bus/pcie otherwise
>>
>> I don't think we'll have a lot of rules, simple boolean fields
>> for the interface should be enough.
>
> What you propose makes sense, the only difference is that the
> boolean fields would be just interface names that can be used as
> the "implements" argument on qom-list-types.
>
> e.g.:
>
> * Hybrid PCI device-types would implement both "legacy-pci-device" and
>   "pcie-device" interfaces.
> * PCIe-only device-types would implement only the "pcie-device"
>   interface.
> * Legacy-PCI-only device-types would implement only the
>   "legacy-pci-device" interface.
>
> Then, the bus instances would have a 'accepted-device-types'
> field:
>
> * A legacy PCI bus would accept only "legacy-pci-device" devices.
> * A PCIe-only bus would accept only "pcie-device" devices.
> * A PCIe bus that accepts legacy PCI devices (the root bus?)
>   would accept both "legacy-pci-device" and "pcie-device"
>   devices.
>
> Then, query-machines would return the list of bus instances that
> machine init creates, containing the bus ID, bus type, and
> accepted-device-types.
>
> Does that make sense?
>

Sure, the described approach solves the problem.

>>
>> This still does not solve the problem that some devices makes
>> sense only on a specific arch.
>
> Right now, we can simply compile out arch-specific devices that
> can never be plugged in a QEMU binary. But if we still want them
> compiled in for some reason, we can categorize them on a
> different type/interface name, and the corresponding machine-type
> would tell management that their buses accept only the
> arch-specific type/interface name.
>

Adding an Interface for each arch could work, yes.


>>
>>>
>>> Incomplete bus lists on some machines
>>> -------------------------------------
>>>
>>> With this series, not all machines classes are changed to add the
>>> full list of device types on the 'supported-device-types'. To
>>> allow the code to be updated gradually, qmp-machine-info.py has a
>>> STRICT_ARCHES variable, that will make the test code require a
>>> complete device type list only on some architectures.
>>>
>>> Out of scope: Configurable buses
>>> --------------------------------
>>>
>>> There's no way to map machine options like "usb=on|off" to
>>> device-types or buses. I plan to propose a new interface that
>>> allows machine options to be mapped to buses/device-types later.
>>>
>>> Out of scope: Deciding where to plug devices
>>> --------------------------------------------
>>>
>>> Once management software discovers which devices can be plugged
>>> to a machine, it still has to discover or define where devices
>>> can/should/will be plugged. This is out of the scope of this
>>> series.
>>>
>>
>> That's a pitty :(
>> I was hoping this series will solve this issue. But if it prepares
>> the grounds for it is also a good step .
>
> The bus ID will be in the scope of v2.
>

Thanks,
Marcel


>>
>>
>>
>> Thanks,
>> Marcel
>>

[...]