[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 11.09.13 at 15:26, Gordan Bobic <gordan@xxxxxxxxxx> wrote: > 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? Just look at set_msi_source_id() as well as domain_context_{mapping,unmap}() (just the most prominent examples): Behavior here heavily depends on the type of the device itself _and_ that of the upstream bridge(s). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |