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

Osier Yang jyang at redhat.com
Wed Dec 26 10:07:41 UTC 2012


On 2012年12月26日 17:12, li guang wrote:
> 在 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?

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.

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




More information about the libvir-list mailing list