[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Gordan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.