Re: Dealing with non-existent BDF devices in VT-d and in the hardware.

[Gordan Bobic <gordan@bobich.net>]

On 03/12/2014 02:22 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 12, 2014 at 09:17:59AM +0000, Jan Beulich wrote:
>>>>> On 11.03.14 at 18:30, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>> To use this hack, apply the
>>> 0001-xen-pci-Introduce-a-way-to-deal-with-buggy-hardware-.patch
>>> to your hypervisor, compile and install.
>>
>> I'm still rather hesitant to consider such a pretty involved
>> workaround for general inclusion. Did you investigate whether
>> leveraging the grouping functionality (iommu_get_device_group())
>> might be possible instead? We're talking about a legacy PCI bridge
>> after all, and if done that way also covering the AMD IOMMU case
>> might be more straightforward (after all that case is missing from
>> your already large patch).
>
> <nods>
>
> I think other people have experienced other non-bridge issues.
> I have CC-ed Gordan on this as he had a LSI card that was misbehaving.

Not one but two different LSI 8-port SAS cards, and an Adaptec 16-port 
SAS card. As far as I can tell this is related to the cards not being 
native PCIe but being bridged. The very latest LSI cards are native PCIe 
and don't seem to suffer from the same problem (I only did 5 minutes of 
testing with a borrowed recent LSI card, but the problem is very obvious 
(disks don't show up!), so I'm quite confident the problem doesn't 
manifest on the new one.

> I am curious to see what his lspci and lspci -vt looks for his culprit.

I'll try to put this together in a few days when I have the test machine 
set up.

>> While looking over this, I found that this only has a use in xend -
>> another xl deficiency? And only for checking purposes, rather
>
> Gosh.

That could make it rather difficult to test with latest 4.4.x code...

Gordan