On Sun, 2016-11-13 at 10:55 -0500, Laine Stump wrote: > > 2) pci-bridge was requested with user-supplied address that is on a > > nonexistent bus, and that bus number is >1 over the current last bus > > (i.e. there is a gap in the controller indexes). This would happen if, > > for example, someone put this in their xml: > > > > <controller type='pci' index='0' model='pci-root'/> > > <controller type='pci' index='2' model='pci-bridge'/> > > > > (if libvirt was setting the index, it would have set the index for the > > pci-bridge to '1'). > > > > a) pci-root - okay, here's where what you're saying would apply - > > we need to add extra pci-bridges > > to fill in the "empty space" in the list of controllers. > > > > b) pcie-root - actually we have the same issue in this case. > > > > Personally I think that it's nonsensical for a user to do that, and > > trying to support "empty regions" in the PCI address space by > > auto-adding pci-bridges is pointless busywork, but we have supported > > it in the past, so I guess we need to now. Sigh. > > But wait! Look at the example above - that's *exactly* the odd case that > patch 11/17 (the RFC patch that we agreed wasn't worthwhile) remedies. > > Even without that RFC patch, if you look at the code that creates a > PCIAddressSet (qemuDomainPCIAddressSetCreate()), you'll see that during > the initial creation, the unused bus numbers are filled in with > pcie-root-port or pci-bridge controllers, i.e. the PCIAddressSet is > never "sparse", and thus virDomainPCIAddressSetGrow() is guaranteed > never to encounter the case above. So you're asking for a solution to a > nonexistent problem. Yup, I had noticed that :) I'm still a bit unconvinced that function is a rock-solid as I'd like it to be, but seeing as I've made you go over it several times and it has resisted all my attempts to break it, the only reasonable thing I can do is to ACK your changes and stop being in the way of progress. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list