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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 16, 2013 at 12:35:29PM -0400, Laine Stump wrote:
> On 04/15/2013 06:14 PM, Don Dutile wrote:
> > On 04/15/2013 04:09 PM, Laine Stump wrote:
> >> On 04/15/2013 06:29 AM, Daniel P. Berrange wrote:
> >>> On Fri, Apr 12, 2013 at 11:46:15AM -0400, Laine Stump wrote:
> >>>> On 04/11/2013 07:23 AM, Michael S. Tsirkin wrote:
> >>>>> On Thu, Apr 11, 2013 at 07:03:56AM -0400, Laine Stump wrote:
> >>>>>> On 04/10/2013 05:26 AM, Daniel P. Berrange wrote:
> >>>>>>>>> So if we later allowed for mutiple PCI roots, then we'd have
> >>>>>>>>> something
> >>>>>>>>> like
> >>>>>>>>>
> >>>>>>>>>     <controller type="pci-root" index="0">
> >>>>>>>>>       <model name="i440FX"/>
> >>>>>>>>>     </controller>
> >>>>>>>>>     <controller type="pci-root" index="1">
> >>>>>>>>>       <model name="i440FX"/>
> >>>>>>>>>     </controller>
> >>>>>>>>>     <controller type="pci" index="0">  <!-- Host bridge 1 -->
> >>>>>>>>>       <address type='pci' domain='0' bus='0' slot='0''/>
> >>>>>>>>>     </controller>
> >>>>>>>>>     <controller type="pci" index="0">  <!-- Host bridge 2 -->
> >>>>>>>>>       <address type='pci' domain='1' bus='0' slot='0''/>
> >>>>>>>>>     </controller>
> >>>>
> >>>> There is a problem here - within a given controller type, we will now
> >>>> have the possibility of multiple controllers with the same index - the
> >>>> differentiating attribute will be in the<address>  subelement, which
> >>>> could create some awkwardness. Maybe instead this should be handled
> >>>> with
> >>>> a different model of pci controller, and we can add a "domain"
> >>>> attribute
> >>>> at the toplevel rather than specifying an<address>?
> >>> IIUC there is a limit on the number of PCI buses you can create per
> >>> domain, due to fixed size of PCI addresses. Google suggests to me
> >>> the limit is 256. So for domain 1, we could just start index at
> >>> 256, and domain 2 at 512, etc
> >>
> >> Okay. Whether we choose that method, or a separate domain attribute, I'm
> >> satisfied that we'll be able to find a way to solve it when the time
> >> comes (and it hasn't yet), so we can ignore that problem for now.
> >>
> >>
> > *PLEASE* don't create a new/competing naming/numbering scheme for
> > differentiating
> > PCI domains.... as much as I dislike the overuse of the term 'domain',
> > it's what
> > is used.  No sane person is going to look to assign PCI bus numbers >
> > 256 in order
> > to get new/different domains.
> > The name sucks, but that's what it's called in the code, and what
> > customers are use to
> 
> 
> I infer from this that you're okay with:
> 
>   <controller type='pci' domain='n' index='n'>
> 
> when defining a new controller (using "index" instead of "bus" is a bit
> bothersome, but it is following current convention; should we reconsider
> and just call it "bus" this time?), and:

'index' is standard naming across all libvirt <controller> elements
and we should do anything different for PCI. For the same reason I
don't want us inventing a new 'domain' attribute here either.

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]