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
[...]
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
