在 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