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

[Gordan Bobic <gordan@xxxxxxxxxx>]

On Wed, 11 Sep 2013 14:22:51 +0100, "Jan Beulich" <JBeulich@xxxxxxxx> 
wrote:
> > > > 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.
Not sure I follow. Why do we need to know the device type?

Gordan

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