Due to its unpopularity, I've removed the "hotpluggable" attribute
that was in V1 of this patchset, and also auto-assign *all* devices
(except primary video and USB2 for historical reasons) to hotpluggable
slots only (rather than assigning devices to the non-hotpluggable
pcie-root if libvirt doesn't currently allow hotplugging those
devices). So these patches have *NO* new configuration - they are just
correcting bad (or at least suboptimal) behavior, and should thus be
reasonably uncontroversial :-)
The first patch corrects an error in where pci-bridge can be plugged
in, which isn't really about using more PCI, but *is* about getting
devices plugged into the right kind of slots. (tl;dr - a pci-bridge
works when plugged into pcie-root, but people who know about PCI tell
me that it's "not proper" to do so, so now we don't unless
specifically told to).
Patch 2 puts virtio devices into PCIe slots when they support it,
patch 3 puts the new e1000e network device (which is a PCIe version of
the Intel e1000) into a PCIe slot (as long as the machine has PCIe),
and patch 3 does the same for the NEC xhci USB3 controller - all of
these devices present as PCie devices when in a PCIe slot, and as PCI
devices otherwise, and there is no doubt that preferring PCIe is
desirable (legacy PCI controllers only exist on Q35 and other
PCIe-capable machinetypes as a crutch to use when you have to use a
device that is legacy-PCI-only).
One exception that isn't handled in this series is that when a virtio
device has --disable-modern=on, it will always be a PCI device. Since
Jan's patches to support setting that option aren't in yet, I don't do
anything about it.
Another caveat - since the auto-adding of PCI controllers will
currently only add pci-bridge devices, in order for these patches to
be useful, you'll need to manually add a
<controller type='pci' model='pcie-root-port'/>
for each device. Before pushing these patches, I plan to add another
patch that auto-adds pcie-*-port as needed, but wanted to post what I
have now to get a head start on reviews (especially since many
reviewers will be at KVM Forum next week).
Finally, if you want to try out these patches, you'll need to apply
them on top of jtomko's patch "Introduce
QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY", from the most recent version of
his virtio version patches.
Laine Stump (4):
conf: restrict what type of buses will accept a pci-bridge
qemu: assign virtio devices to PCIe slot when appropriate
qemu: assign e1000e network devices to PCIe controllers when
appropriate
qemu: assign nec-xhci (USB3) controller to a PCIe address when
appropriate
src/conf/domain_addr.c | 29 +++-
src/conf/domain_addr.h | 4 +-
src/qemu/qemu_domain_address.c | 69 ++++++++--
tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +-
tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 58 ++++++++
tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml | 67 +++++++++
.../qemuxml2argv-q35-virtio-pci.args | 58 ++++++++
.../qemuxml2argv-q35-virtio-pci.xml | 67 +++++++++
.../qemuxml2argv-q35-virtio-pcie.args | 56 ++++++++
tests/qemuxml2argvtest.c | 45 +++++-
.../qemuxml2xmlout-autoindex.xml | 10 +-
.../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 152 +++++++++++++++++++++
.../qemuxml2xmlout-q35-virtio-pci.xml | 152 +++++++++++++++++++++
tests/qemuxml2xmltest.c | 40 ++++++
14 files changed, 788 insertions(+), 29 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.args
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml
--
2.7.4