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

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

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@xxxxxxxxxx> wrote:
To use this hack, apply the
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).


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


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


Xen-devel mailing list



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