[libvirt] [PATCH v3 15/18] qemu: auto-add pcie-root-port/dmi-to-pci-bridge controllers as needed

[Laine Stump]

On 10/10/2016 02:14 PM, Andrea Bolognani wrote:
>> +    } else if (flags & VIR_PCI_CONNECT_TYPE_PCI_BRIDGE) {
>> >+        model = VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE;
> I'm not so clear on this bit: if we're growing the address
> set to plug in a pci-bridge, can we just go ahead and assume
> a dmi-to-pci-bridge is what we need? What about eg. pseries
> machine types, where dmi-to-pci-bridge is not usable?
>

What can you plug a pci-bridge into on a pseries machine? For all 
machinetypes, if there is an unaddressed pci-bridge in the config and 
there is a slot available that accepts a pci-bridge (i.e. pci-root, 
pci-bridge, or dmi-to-pci-bridge) then we won't be calling 
virDomainPCIAddressSetGrow() in the first place (since it's only called 
if no empty slot with correct flags can be found). And I don't know 
about pseries, but for 440fx, if there isn't a matching empty slot that 
accepts a pci-bridge at that point, then it's not possible to add one 
(you already have the one and only pci-root, and you're already trying 
to add a pci-bridge --> if you have to add a pci-bridge in order to add 
a pci-bridge, then you're in an infinite recursion).


So a dmi-to-pci-bridge is the only thing that could possibly help, and 
in the cases where there is no pcie-root, it would just mean that you 
would get an error later when you're told there's no place to plug in 
the dmi-to-pci-bridge. So it makes sense for me to add a check here to 
see if the model of addrs->buses[0] is PCIE_ROOT, and only try adding 
the dmi-to-pci-bridge in that case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161013/637d5c0f/attachment-0001.htm>