On 2012年12月26日 16:28, Osier Yang wrote:
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.
>
>> 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,
By the way, what I get from Michael S. Tsirkin is: More than
2 bridges *should* work.
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.
> 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
>>
>>
>
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list