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

[Gordan Bobic <gordan@bobich.net>]

 On Wed, 11 Sep 2013 14:03:14 +0100, "Jan Beulich" <JBeulich@suse.com> 
 wrote:
>>>> On 11.09.13 at 14:45, Gordan Bobic <gordan@bobich.net> 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.

 Gordan