]> xenbits.xensource.com Git - libvirt.git/commit
conf: allow hotplugging "legacy PCI" device to manually addressed PCIe slot
authorLaine Stump <laine@laine.org>
Fri, 9 Sep 2016 19:26:34 +0000 (15:26 -0400)
committerLaine Stump <laine@laine.org>
Mon, 12 Sep 2016 18:46:10 +0000 (14:46 -0400)
commitb87703cf79559157404667628802d7fe8f9f19a6
treebe1c69fb52480f31b666d7b0e3c2706fbdbd0489
parent0276015325a746f2cd26ef0fddfc682cf641423f
conf: allow hotplugging "legacy PCI" device to manually addressed PCIe slot

In a full domain config, libvirt allows overriding the normal PCI
vs. PCI Express rules when a device address is explicitly provided
(so, e.g., you can force a legacy PCI device to plug into a PCIe port,
although libvirt would never do that on its own). However, due to a
bug libvirt doesn't give this same leeway when hotplugging devices. On
top of that, current libvirt assumes that *all* devices are legacy
PCI. The result of all this is that it's impossible to hotplug a
device into a PCIe port, even if you manually add the PCI address.

This can all be traced to the function
virDomainPCIAddressEnsureAddr(), and the fact that it calls
virDomainPCIaddressReserveSlot() for manually set addresses, and that
function hardcodes the argument "fromConfig" to false (meaning "this
address was auto-assigned, so it should be subject to stricter
validation").

Since virDomainPCIAddressReserveSlot() is just a one line simple
wrapper around virDomainPCIAddressReserveAddr() (adding in a hardcoded
reserveEntireSlot = true and fromConfig = false), all that's needed to
solve the problem with no unwanted side effects is to replace that
call for virDomainPCIAddressReserveSlot() with a direct call to
virDomainPCIAddressReserveAddr(), but with reserveEntireSlot = true,
fromConfig = true. That's what this patch does.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1337490
src/conf/domain_addr.c