[PATCH] Support PCIe Alternative RID Interpretation (ARI)

[Ryan Stone]

On Sun, Mar 16, 2014 at 10:12 AM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> This is expected, but it would break VT-d busdma, I think.
>
> This is not said in the VT-d spec about ARI, but I believe that
> DMAR would split the function number by 7-3/2-0 bits, same as for
> the non-ARI devices.  Then the transactions will be translated by
> the wrong context.

Ah, good catch.  I took a quick look at the spec and the code, and I
believe that I see the problem.  I think that the proper solution is
to add a new method, pcib_get_rid(), that returns (bus << 8) | (slot
<< 5) | func for non-ARI devices and (bus << 8) |  func for ARI
devices.  Then we could add a pci_get_rid() that just calls the pcib
method, and the DMAR code could be changed to work in terms of the RID
instead of bus/slot/function.  My reading of the spec is that VT-d is
really implemented in terms of the RID anyway, but the spec authors
took pains to give examples in terms of bus/slot/function because
that's how the software developers understand things.

Do you know if bhyve's pci passthrough code uses the same code to add
DMAR entries as the busdma code?  If not I'll have to track down how
bhyve does it because it would likely have the same problem.

> From other minor notes, having additional line for "ARI enabled"
> message under bootverbose would make already excessive PCI config
> dump even more problematic.

I can remove it.  At the time I wanted some kind of indication that
ARI was being used, but pciconf can tell you that now so it's not
really necessary.