Re: [Xen-devel] Multi-bridged PCIe devices (Was: Re: iommuu/vt-d issues with LSI MegaSAS (PERC5i))

["Jan Beulich" <JBeulich@xxxxxxxx>]

 >>> On 11.09.13 at 15:10, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
> On Wed, 11 Sep 2013 14:03:14 +0100, "Jan Beulich" <JBeulich@xxxxxxxx> 
>  wrote:
>>>>> On 11.09.13 at 14:45, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>>>  dmesg, xl dmesg, lspci -vvvnn and lspci -tvnn output is attached.
>>>
>>>  I'll try adding one of my LSI cards and see the comparative
>>>  behaviour. Right now I don't even know if the phantom device
>>>  is on the SAS card or the motherboard.
>>
>> The Adaptec card being the only thing on bus 0f makes it pretty
>> likely that this other device also is on that card.
>>
>> I guess the issue is mainly because the device itself is a PCI one,
>> while the immediately upstream bridge (where I mean only the
>> visible one) is PCIe. There _must_ be a PCIe-PCI bridge between
>> them. And as long as firmware doesn't know about that bridge
>> and the bridge doesn't properly handle config space accesses to
>> it, such a device just can't be used with an IOMMU (without some
>> yet to be invented workaround).
> 
>  I'm actually thinking about Konrad's proposed hack in that
>  thread from 3 years ago. If the device IDs are parameterized
>  out rather than hard-coded, then this could work in nearly the
>  same was as xen-pciback in terms of usage. Pass the phantom
>  device IDs as parameters to the module. Done that way it
>  might even be considered clean enough to be fit for public
>  consumption.

Except that, short of being able to determine it via config
space reads, we also need the resulting command line option
to tell us that what kind of device that is.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel