On Mon, 2016-11-07 at 14:50 -0500, Laine Stump wrote: > I'm undecided if it is worthwhile to add this... > > Up until now it has been legal to have something like this in the xml: > > <controller type='pci' model='pcie-root' index='0'/> > <controller type='pci' model='pci-bridge' index='2'/> > > (for example, see the existing test case > "usb-controller-default-q35"). This is handled in > qemuDomainPCIAddressSetCreate() when it's adding in controllers to > fill holes in the indexes.) > > Since we have always added the following to every config: > > <controller type='pci' model='dmi-to-pci-bridge' index='1'/> > > there has always been a proper place for the unaddressed pci-bridge to > plug in. > > A upcoming commit will eliminate the forced adding of a > dmi-to-pci-bridge to *every* Q35 domain config, though. This would > mean the above-mentioned test case (and one other) would begin to > fail. There are two possible solutions to this problem: > > 1) change the test cases, and made the above construct an error (note > that in the future it will work just fine to not list *any* pci > controller, and they will all be auto-added as needed). > > or > > 2) This patch, which specifically looks for the case where we have a > pci-bridge (but no dmi-to-pci-bridge) in a PCIe domain config and > auto-adds the necessary dmi-to-pci-bridge. This can only work in the > case that the pci-bridge has been given an index such that there is an > unused index with a lower value for the dmi-to-pci-bridge to occupy. > > This seems like a kind of odd corner case that nobody should need to > do in the future anyway. On the other hand, I already wrote the code > and it works, so I might as well send it and see what opinions (if > any) it generates. I say let's forget about this. I'm fairly certain nobody is using this ludicrous pattern outside of our test suite, and even if they did their guests configurations would already have had the dmi-to-pci-bridge added long ago, so no risks of breakage there. So, unless somebody has very compelling arguments for maintaining such a "feature", consider this a NACK -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list