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