[libvirt] [PATCH 0/3] add pci-bridge device and address type

[li guang]

在 2012-12-26三的 16:28 +0800，Osier Yang写道：
> On 2012年12月26日 16:12, li guang wrote:
> > 在 2012-12-26三的 15:38 +0800，Osier Yang写道：
> >> On 2012年12月26日 09:00, liguang wrote:
> >>> Now, it's unnecessary to arrange devices into multi-pci-bus,
> >>> for example:
> >>>       <sound model='ac97'>
> >>>         <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
> >>>       </sound>
> >>>      <video>
> >>>         <model type='cirrus' vram='9216' heads='1'/>
> >>>         <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/>
> >>>       </video>
> >>> libvirt will complain about "bus != 0",
> >>> fortunately, qemu supports pci-to-pci bridge,
> >>> if we want to use multi-pci-bus, we can define
> >>> 2 pci bridge devices then attach 1 to the other
> >>> as a subordinate pci-bus, so, 2 pci-buses appear.
> >>> for example:
> >>>       <pci-bridge type='root'/>
> >>>       <pci-bridge type='subordinate'>
> >>>         <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
> >>>       </pci-bridge>
> >>>       <sound model='ac97'>
> >>>         <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/>
> >>>       </sound>
> >>>      <video>
> >>>         <model type='cirrus' vram='9216' heads='1'/>
> >>>         <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
> >>>       </video>
> >>
> >> I think this is rather not workable, E.g. how to known the video device
> >> attached to which pci bridge if there are multiple pci bridges?
> >
> > please bear in mind bus 0 is root bridge, bus 1 is subordinate bridge,
> > and so forth, which was implemented in my patch 2/3
> 
> That doesn't answer the question.

video attached to root bridge(bus 0), slot 2
sound attached to bus 1 , slot 1

> 
> >
> >> And the
> >> new address type "pci-bridge" looks bogus, as the address properties of
> >> a pci bridge are exactly same with a normal pci device.
> >>
> >>   From the qemu patch:
> >>
> >>           -device pci-bridge,id=bridge1 \
> >>           -netdev user,id=u \
> >>           -device ne2k_pci,id=net2,bus=bridge1,netdev=u
> >>
> >> I think what we only need is to describe the relapship between pci
> >> bridge and pci bridge (if it's supported, the two types "root" and
> >> "subordinate" are not enough to describe the relatioship), also pci
> >> device and pci bridge.
> >
> > relationship between pci-bus and devices are embedded, just like
> > pci.0, e.g.
> > <address type='pci' domain='0x0000' bus='0x00' slot='0x04'
> > function='0x0'/>
> > means a device sitting on bus pci.0 slot 4
> > then after my changes
> > <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04'
> > function='0x0'/>
> > would have the same mean
> > relationship between pci-bridges are primary and secondary,
> > (as far as I know qemu doesn’t support multi-pci-bridges at present)
> > so root and subordinate attribute may be enough,
> 
> No, even it's not supported now, the proposed XML should be
> designed compatible enough for future. Note that as long
> as a new XML is added, it can't changed/removed for back-compact,
> so when introducing new XMLs, you should consider the future.
> 
> And on other hand, the introduced XML should be general
> enough for all drivers, not only QEMU.
> 
> Anyway, regardless of the current qemu implementation, I think
> you should refer to the specification of PCI SGI, so that the
> proposed XML could be compatible enough for the future.

yes, I will, but any problem with the pci-bridge definition in XML?
it's just a simple element.
can you tell more details about problem of this new definition?

> 
> > every subordinate will attach to root bridge, and has its own slot.
> >
> >>
> >> To describe the relationship between bridges, perhaps we will need
> >> "parent" and "child" properties for<pcibridge>  device.
> >>
> >> To describe the relatioship between a pci device and a pci bridge,
> >> a property like "bridge" for general pci device should be enough.
> >> In this case, another property for<pcibridge>  is needed, to
> >> indentify it, such as "id" or "name".
> >
> > only relationship is not enough, it's unsuitable for passing '-device
> > pci-bridge' to qemu, so I define a new device and address type for
> > pci-bridge in libvirt.
> >
> >>
> >> Regards,
> >> Osier
> >>
> >>
> >
> 

-- 
regards!
li guang