mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-10-07 14:55:46 +00:00
0702f48ef4
Previously libvirt would only add pci-bridge devices automatically when an address was requested for a device that required a legacy PCI slot and none was available. This patch expands that support to dmi-to-pci-bridge (which is needed in order to add a pci-bridge on a machine with a pcie-root), and pcie-root-port (which is needed to add a hotpluggable PCIe device). It does *not* automatically add pcie-switch-upstream-ports or pcie-switch-downstream-ports (and currently there are no plans for that). Given the existing code to auto-add pci-bridge devices, automatically adding pcie-root-ports is fairly straightforward. The dmi-to-pci-bridge support is a bit tricky though, for a few reasons: 1) Although the only reason to add a dmi-to-pci-bridge is so that there is a reasonable place to plug in a pci-bridge controller, most of the time it's not the presence of a pci-bridge *in the config* that triggers the requirement to add a dmi-to-pci-bridge. Rather, it is the presence of a legacy-PCI device in the config, which triggers auto-add of a pci-bridge, which triggers auto-add of a dmi-to-pci-bridge (this is handled in virDomainPCIAddressSetGrow() - if there's a request to add a pci-bridge we'll check if there is a suitable bus to plug it into; if not, we first add a dmi-to-pci-bridge). 2) Once there is already a single dmi-to-pci-bridge on the system, there won't be a need for any more, even if it's full, as long as there is a pci-bridge with an open slot - you can also plug pci-bridges into existing pci-bridges. So we have to make sure we don't add a dmi-to-pci-bridge unless there aren't any dmi-to-pci-bridges *or* any pci-bridges. 3) Although it is strongly discouraged, it is legal for a pci-bridge to be directly plugged into pcie-root, and we don't want to auto-add a dmi-to-pci-bridge if there is already a pci-bridge that's been forced directly into pcie-root. Although libvirt will now automatically create a dmi-to-pci-bridge when it's needed, the code still remains for now that forces a dmi-to-pci-bridge on all domains with pcie-root (in qemuDomainDefAddDefaultDevices()). That will be removed in a future patch. For now, the pcie-root-ports are added one to a slot, which is a bit wasteful and means it will fail after 31 total PCIe devices (30 if there are also some PCI devices), but helps keep the changeset down for this patch. A future patch will have 8 pcie-root-ports sharing the functions on a single slot. |
||
|---|---|---|
| .. | ||
| capabilities.c | ||
| capabilities.h | ||
| cpu_conf.c | ||
| cpu_conf.h | ||
| device_conf.c | ||
| device_conf.h | ||
| domain_addr.c | ||
| domain_addr.h | ||
| domain_audit.c | ||
| domain_audit.h | ||
| domain_capabilities.c | ||
| domain_capabilities.h | ||
| domain_conf.c | ||
| domain_conf.h | ||
| domain_event.c | ||
| domain_event.h | ||
| domain_nwfilter.c | ||
| domain_nwfilter.h | ||
| interface_conf.c | ||
| interface_conf.h | ||
| netdev_bandwidth_conf.c | ||
| netdev_bandwidth_conf.h | ||
| netdev_vlan_conf.c | ||
| netdev_vlan_conf.h | ||
| netdev_vport_profile_conf.c | ||
| netdev_vport_profile_conf.h | ||
| network_conf.c | ||
| network_conf.h | ||
| network_event.c | ||
| network_event.h | ||
| networkcommon_conf.c | ||
| networkcommon_conf.h | ||
| node_device_conf.c | ||
| node_device_conf.h | ||
| node_device_event.c | ||
| node_device_event.h | ||
| numa_conf.c | ||
| numa_conf.h | ||
| nwfilter_conf.c | ||
| nwfilter_conf.h | ||
| nwfilter_ipaddrmap.c | ||
| nwfilter_ipaddrmap.h | ||
| nwfilter_params.c | ||
| nwfilter_params.h | ||
| object_event_private.h | ||
| object_event.c | ||
| object_event.h | ||
| secret_conf.c | ||
| secret_conf.h | ||
| snapshot_conf.c | ||
| snapshot_conf.h | ||
| storage_conf.c | ||
| storage_conf.h | ||
| storage_event.c | ||
| storage_event.h | ||
| virchrdev.c | ||
| virchrdev.h | ||
| virdomainobjlist.c | ||
| virdomainobjlist.h | ||
| virsecretobj.c | ||
| virsecretobj.h | ||