[libvirt] new libvirt "pci" controller type and pcie/q35 (was Re: [PATCH 4/7] add pci-bridge controller type)

[Daniel P. Berrange]

On Tue, Apr 16, 2013 at 12:05:40PM -0400, Laine Stump wrote:
> On 04/15/2013 05:58 PM, Michael S. Tsirkin wrote:
> > On Mon, Apr 15, 2013 at 11:27:03AM -0600, Alex Williamson wrote:
> >> On Fri, 2013-04-12 at 11:46 -0400, Laine Stump wrote:
> >>> On 04/11/2013 07:23 AM, Michael S. Tsirkin wrote:
> > it's intended for multi-root support for legacy OSes.
> >
> >> "index" is confusing to me.
> 
> 
> index is being used just because that's been the convention for other
> controller types - when there are multiple controllers of the same type,
> each is given an index, and that's used in the "child" devices to
> indicate which of the parent controllers they connect to.
> 
> 
> > I'd prefer ID for bus not a number, I'm concerned users will
> > assume it's bus number and get confused by a mismatch.
> 
> So you would rather that they were something like this?
> 
> <controller type='pci' bus='pci.0'>
>   <model type='pci-root'/>
> </controller>
> <interface type='blah'>
>   ...
>   <address type='pci' domain='0' bus='pci.0' slot='0' function='0'/>
> </interface>
> 
> The problem is that the use of numeric bus IDs is fairly deeply
> ingrained in libvirt; every existing libvirt guest config has device
> addresses specifying "bus='0'" Switching to using an alphanumeric ID
> rather than a simple number would require extra care to maintain
> backward compatibility with all those existing configs and previous
> versions of libvirt that might end up being the recipient of xml
> generated by a newer libvirt. Because of this, at the very least the
> pci.0 bus must be referred to as bus='0'; once we've done that, we might
> as well refer to them *all* numerically (anyway, even if names were
> allowed, I'm sure everybody would just call them '1', '2', (or at the
> very most "pci.1", "pci.2") etc. anyway.

We explicitly do *NOT* want to use something like 'pci.1' because
that is a QEMU specific naming concept. The use of numeric IDs
was a delibrate choice for libvirt addressing and not something we
are going to change.


> >>> 5) to support multiple domains, we can simply add a "domain" attribute
> >>> to the toplevel of controller.
> >>>
> >> Or this Wouldn't even be unnecessary if we supported a 'pci-root-addr'
> >> address type for the above with the default being domain=0, bus=0?  I
> >> suppose it doesn't matter whether it's a separate attribute or new
> >> address type though.  Thanks,
> 
> I think you're mixing up the purpose of the <address> element vs the "index" attribute in the main <controller> element. To clarify, take this example:
> 
> 
>     <controller type='pci' index='3'>
>       <model type='pci-bridge'/>
>       <address domain='0' bus='1' slot='9' function='0'/>
>     </controller>
> 
> This controller is connected to slot 9 of the already-existing bus 1. It provides a bus 3 for other devices to connect to. If we wanted to start up a domain 1, we would do something like this:
> 
>     <controller type='pci' domain='1' index='0'>
>       <model type='pci-root'/>
>     </controller>
> 
> This would give us a PCI bus 0 in domain 1. You could then connect a pci-bridge to it like this:
> 
> 
>     <controller type='pci' domain='1' index='1'>
>       <model type='pci-bridge'/>
>       <address type='pci' domain='1' bus='0' slot='1' function='0'/>
>     </controller>
> 
> The <address> tells us that this new bus connects to slot 1 of PCI bus 0 in domain 1. The <controller domain='1' index='1'> tells us that there is now a new bus other devices can connect to that is at domain='1' bus='1'.

Can we just leave multi-domains out of this discussion for now. IMHO
they are just causing more confusion to an already complicated problem.
Lets focus on just solving the problem of PCI bridges which is what we
actually need right now.

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 :|