Re: [libvirt] [RFC v2 00/20] qmp: Report bus information on 'query-machines'
On Fri, Nov 25, 2016 at 08:05:36PM -0200, Eduardo Habkost wrote:
[...]
> Example output
> --
>
> TODO: update it.
I've forgot to update it. Here it is:
{
"return": [
{
"cpu-max": 1,
"hotpluggable-cpus": false,
"name": "none"
},
[...]
{
"cpu-max": 1,
"hotpluggable-cpus": false,
"name": "xenpv"
},
[...]
{
"name": "pc-i440fx-2.8",
"always-available-buses": [
{
"bus-id": "ide.1",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "ide.0",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "isa.0",
"bus-type": "ISA",
"accepted-device-types": [
"isa-device"
]
},
{
"bus-id": "i2c",
"bus-type": "i2c-bus",
"accepted-device-types": [
"i2c-slave"
]
},
{
"bus-id": "floppy-bus.0",
"bus-type": "floppy-bus",
"accepted-device-types": [
"floppy"
]
},
{
"bus-id": "pci.0",
"bus-type": "PCI",
"accepted-device-types": [
"legacy-pci-device"
]
},
{
"bus-id": "sysbus",
"bus-type": "System",
"accepted-device-types": [
"sys-bus-device"
]
}
],
"alias": "pc",
"is-default": true,
"cpu-max": 255,
"hotpluggable-cpus": true
},
[...]
{
"cpu-max": 1,
"hotpluggable-cpus": true,
"always-available-buses": [
{
"bus-id": "ide.1",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "ide.0",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "isa.0",
"bus-type": "ISA",
"accepted-device-types": [
"isa-device"
]
},
{
"bus-id": "floppy-bus.0",
"bus-type": "floppy-bus",
"accepted-device-types": [
"floppy"
]
},
{
"bus-id": "sysbus",
"bus-type": "System",
"accepted-device-types": [
"sys-bus-device"
]
}
],
"name": "isapc"
},
[...]
{
"cpu-max": 128,
"hotpluggable-cpus": true,
"always-available-buses": [
{
"bus-id": "ide.1",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "ide.0",
"bus-type": "IDE",
"accepted-device-types": [
"ide-device"
]
},
{
"bus-id": "isa.0",
"bus-type": "ISA",
"accepted-device-types": [
"isa-device"
]
},
{
"bus-id": "pci.0",
"bus-type": "PCI",
"accepted-device-types": [
"legacy-pci-device"
]
},
{
"bus-id": "i2c",
"bus-type": "i2c-bus",
"accepted-device-types": [
"i2c-slave"
]
},
{
"bus-id": "floppy-bus.0",
"bus-type": "floppy-bus",
[libvirt] [RFC v2 00/20] qmp: Report bus information on 'query-machines'
Changes v1 -> v2: * v1 series subject was: "qmp: Report supported device types on 'query-machines'" * Now we return additional bus information: bus ID, bus type, and the list of accepted device types on each bus * Now hotplug can be covered because accepted-device-types can be set by individual bus instances if necessary * Now the new field is optional, and every machine having the new field are now validated in "strict mode" on test code (meaning all buses must be present on the list) * TODO: only PC was converted, machines from other architectures don't include the field yet * Legacy-PCI vs PCIe is now handled: * PCIDeviceClass::is_express field was removed * Defined INTERFACE_LEGACY_PCI_DEVICE and INTERFACE_PCIE_DEVICE, buses and devices now report appropriate interface names * Now PCIe buses can return the right information because each bus instance can set its own accepted-device-types list * TODO: PCIe pci-bridge classes need to be changed to not include INTERFACE_LEGACY_PCI_DEVICE * TODO: replace q35 hack with appropriate code that set Legacy-PCI rules in PCI code * Removed patches from v1: * pc: Initialize default bus lists * s390x: Initialize default bus lists * arm: Initialize default bus lists * mips: Initialize default bus lists * ppc: Initialize default bus lists * qdev: Add device_class_set_bus_type() function (validation is more difficult with the PCI/PCIe rules, plan is to try to remove DeviceClass::bus_type field, se "Limitations" below) * See individual patches for additional details 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. Even after the machine is initialized, there's no way to map existing bus types to supported device types unless management software hardcodes the mapping between bus types and device types. Example: floppy support on q35 vs i440fx There's no way for libvirt to find out that there's no floppy controller on pc-q35-* machine-types by default. With this series, pc-i440fx-* will report "floppy" as a supported device type, but pc-q35-* will not. Example: Legacy PCI vs vs PCIe devices -- Some devices require a PCIe bus to be available, others work on both legacy PCI and PCIe, while others work only on a legacy PCI bus. Currently management software has no way to know which devices can be added to a given machine, unless it hardcodes machine-type names and device-types names. Example: spapr and PCIe root bus See the thread at: Subject: [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default If we make new spapr machine-type versions create a PCIe root bus, management software will need a way to find out: 1) The type of the default bus for the machine type; 2) The ID of the default bus for the machine type. Otherwise, management software will have to hardcode it based on machine-type version. The proposed interface should solve this problem. The Proposed Interface == Bus info on query-machines -- This series adds a new field to the output of 'query-machines': 'always-available-buses'. It will contain a a list of MachineBusInfo structs. MachineBusInfo will contain: * bus-id: The bus ID * bus-type: The bus type * accepted-device-types: A list of accepted device types for the bus. bus-id can be used to find out what's the right "bus" argument to be used when adding a device to the machine configuration (e.g. when using -device and device_add). accepted-device-types can be used as the 'implements' argument on the 'qom-list-types' command, to find out which device types can be plugged on the bus. accepted-device-types property on bus objects - This series also adds a 'accepted-device-types' property to bus objects, so management software can check which kinds of devices can be plugged at runtime. Example output -- TODO: update it. Considered alternatives === Indirect mapping (machine => bus => device) --- This RFC implements a mechanism to implement ax machine-type => accepted-device-types mapping. An alternative solution I considered was to expose an indirect mapping: machine-type => default-bus-types followed by bus-type => accepted-device-types. But some buses have no correct bus-type => accepted-device-types mapping. PCIe buses, for example, may or may not accept legacy PCI buses, depending on the machine and the bus topology. imposes less restrictions on how the device and bus type hierarchy is implemented inside QEMU. There's still a machine-type => bus-type => device-type mapping implemented internally, but it is an implementation detail on the current version, and
