[PATCH] Support PCIe Alternative RID Interpretation (ARI)

[Konstantin Belousov]

On Sun, Mar 16, 2014 at 11:05:16AM -0400, Ryan Stone wrote:
> 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.
Well, I agree, but the current DMAR driver is also written in term
of bsf.  So using the pci_get_rid() is possible, but adding a
methods like pci_get_fake_slot/func, which would return ARI rid
converted into fake slot and function at the 3/2 boundary is less
work.

Anyway, please add whatever you find suitable as the accessor method,
and I hope to be able to produce a patch that would convert Intel
IOMMU to use it instead of direct manipulations of bsf.

> 
> 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.
I am not aware of bhyve code.  They definitely use their own code
for the passthrough right now.

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

Or stuff it into the already printed line.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140316/e4a07538/attachment.sig>