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: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