On Mon, Apr 08, 2013 at 12:37:49PM -0400, Laine Stump wrote: > On 04/05/2013 03:26 PM, Alex Williamson wrote: > I think we're starting to get closer to the concrete problem that's > bothering me. As I understand it (and again - "what I understand" has > repeatedly been shown to be incorrect in this thread :-): > > * Ihere are multiple different types of devices that provide a bus with > 1 or more "slots" that PCI devices (e.g., the virtio-net-pci device, the > e1000 network device, etc) can be plugged into. > > * In the config for those devices, there is a required (auto-generated > if not explicitly provided) <address> element that indicates what > controller that device is plugged into e.g.: > > <interface type='direct'> > ... > <address type='pci' domain='0' bus='0' slot='3' function='0'/> > ... > </interface> > > * domain is always hardcoded to 0, and in the past bus was also always > hardcoded to 0 because until now there has only been a single place > where PCI devices could be connected - the builtin pci.0 bus, which is a > part of the basic "pc" (and some others) virtual machine and provides 32 > slots. > > * Now we are adding the ability to define new PCI buses, for now just a > single kind - a pci-bridge controller, which itself must connect to an > existing PCI slot, and provides 32 new PCI slots. But in the future > there will be more different types of controllers that provide one or > more PCI slots where PCI devices/controllers can be plugged in. > > * In these patches adding support for pci-bridge, we are making the > assumption that there is a 1:1 correspondence between the "index='n'" > attribute of the pci-bridge controller and the "bus='n'" attribute of > the <address> element in devices that will be plugged into that > controller. So for example if we have: > > > <controller type='pci-bridge' index='1'> > <address type='pci' domain='0' bus='0' slot='10' function='0'/> > </controller> > > and then change the <interface> definition above to say "bus='1'", that > interface device will plug into this new bus at slot 3. > > * So let's assume that we add a new controller called "dmi-to-pci-bridge": > > <controller type='dmi-to-pci-bridge' index='0'/> > > Ignoring for now the question of what address we give in the definition > of *this* device (which is itself problematic - do we need a new "pcie" > address type?), if some device is then defined with > > > <address type='pci bus='0' .../> > > How do we differentiate between that meaning "the pci-ptp controller > that is index='0'" and "the pci-bridge controller that is index='0'"? Do > we need to expand our <address> element further? If, as I think you > suggest, we have multiple different kinds of controllers that provide > PCI slots, each with its own namespace, the current pci address element > is inadequate to unambiguously describe where a pci device should be > plugged in. Hmm yes, you're right - as long as we only have <adress type='pci'> then all <controller> elements should use type='pci' too, and we should just distinguish based on the model name of the controller. So ignore my previous suggestion to have 'pci-bridge' and 'pci-root' types, we can only use type='pci' on <controller> elements. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list