qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed
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.
2016-09-19 18:38:47 +00:00
|
|
|
<domain type='qemu'>
|
|
|
|
|
<name>q35-test</name>
|
|
|
|
|
<uuid>11dbdcdd-4c3b-482b-8903-9bdb8c0a2774</uuid>
|
|
|
|
|
<memory unit='KiB'>2097152</memory>
|
|
|
|
|
<currentMemory unit='KiB'>2097152</currentMemory>
|
|
|
|
|
<vcpu placement='static' cpuset='0-1'>2</vcpu>
|
|
|
|
|
<os>
|
|
|
|
|
<type arch='x86_64' machine='q35'>hvm</type>
|
|
|
|
|
<boot dev='hd'/>
|
|
|
|
|
</os>
|
|
|
|
|
<clock offset='utc'/>
|
|
|
|
|
<on_poweroff>destroy</on_poweroff>
|
|
|
|
|
<on_reboot>restart</on_reboot>
|
|
|
|
|
<on_crash>destroy</on_crash>
|
|
|
|
|
<devices>
|
2017-04-06 16:19:48 +00:00
|
|
|
<emulator>/usr/bin/qemu-system-x86_64</emulator>
|
qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed
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.
2016-09-19 18:38:47 +00:00
|
|
|
<controller type='virtio-serial'/>
|
|
|
|
|
<controller type='scsi' model='virtio-scsi'/>
|
|
|
|
|
<controller type='usb' model='nec-xhci'/>
|
|
|
|
|
<disk type='block' device='disk'>
|
|
|
|
|
<source dev='/dev/HostVG/QEMUGuest1'/>
|
|
|
|
|
<target dev='vdb' bus='virtio'/>
|
|
|
|
|
</disk>
|
|
|
|
|
<filesystem type='mount'>
|
|
|
|
|
<source dir='/export/to/guest'/>
|
|
|
|
|
<target dir='/import/from/host'/>
|
|
|
|
|
</filesystem>
|
|
|
|
|
<video>
|
|
|
|
|
<model type='virtio'/>
|
|
|
|
|
</video>
|
|
|
|
|
<interface type='user'>
|
|
|
|
|
<mac address='00:11:22:33:44:55'/>
|
|
|
|
|
<model type='virtio'/>
|
|
|
|
|
</interface>
|
|
|
|
|
<interface type='user'>
|
|
|
|
|
<mac address='00:11:22:33:44:66'/>
|
|
|
|
|
<model type='e1000e'/>
|
|
|
|
|
</interface>
|
|
|
|
|
<memballoon model='virtio'/>
|
|
|
|
|
<rng model='virtio'>
|
|
|
|
|
<rate bytes='123' period='1234'/>
|
|
|
|
|
<backend model='random'>/dev/urandom</backend>
|
|
|
|
|
</rng>
|
|
|
|
|
<input type='passthrough' bus='virtio'>
|
|
|
|
|
<source evdev='/dev/input/event1234'/>
|
|
|
|
|
</input>
|
|
|
|
|
<input type='mouse' bus='virtio'/>
|
|
|
|
|
<input type='keyboard' bus='virtio'/>
|
|
|
|
|
<input type='tablet' bus='virtio'/>
|
|
|
|
|
</devices>
|
|
|
|
|
</domain>
|
