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

li guang lig.fnst at cn.fujitsu.com
Thu Dec 27 02:02:48 UTC 2012


在 2012-12-27四的 08:47 +0800,li guang写道:
> 在 2012-12-26三的 18:07 +0800,Osier Yang写道:
> 
> > >>
> > >> 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?
> > 
> > The point is how to known the pci device is attached to which
> > pci bridge *if* multiple bridge is supported. I don't think
> > the two types ("root" and "subordinate") could do the work.
> > 
> 
> okay, let me describe the implicit map rule between bridge and device,
> before this, we should bear in mind 1 bridge corresponding to only 1 bus
> 
>      root bridge (bus 0)
>        |
>        ----- subordinate bridge (bus 1) (slot 0, bus 0)
>        |            |
>        |            ----device 0 (slot 0, bus 1)
>        |            |
>        |            ----device 1 (slot 1, bus 1)
>        |
>        ------ device 0 (slot 2, bus 0)
>        |
>      .......
> 
> this map rule was in embedded in my changes.
>  

maybe I have to describe more detail about
the map rule between pci-bridge and devices,

demo XML:
<pci-bridge type='root'/>
<pci-bridge type='secondary'>
   <address type='pci-bridge' bus='0x00' slot='0x00' function='0x0'/>
</pci-bridge>
<pci-bridge type='subordinate'>
   <address type='pci-bridge' bus='0x01' slot='0x00' function='0x0'/>
</pci-bridge>
<device-0>
   <address type='pci-bridge' bus='0x00' slot='0x01' function='0x0'/>
</device-0>
<device-1>
   <address type='pci-bridge' bus='0x01' slot='0x00' function='0x0'/>
</device-1>
<device-2>
   <address type='pci-bridge' bus='0x02' slot='0x00' function='0x0'/>
</device-2>

will have following structure:

	 root bridge (bus 0)
             |
             -----secondary bridge (bus 1) (bus 0, slot 0)
             |         |
             |         ------subordinate bridge (bus 2) (bus 1, slot 0)
             |         |           |
             |         |           -------device 2 (bus 2, slot 0)
             |         |  
             |         ------device 1 (bus 1, slot 1)
             |
             -----device 0 (bus 0, slot 1)



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





More information about the libvir-list mailing list