[PATCH] Support PCIe Alternative RID Interpretation (ARI)

[Neel Natu]

Hi Ryan,

On Sun, Mar 16, 2014 at 8:05 AM, Ryan Stone <rysto32 at gmail.com> 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.
>
> 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.
>

bhyve has a different implementation of the VT-d driver although
transitioning to x86/iommu is long overdue.

In any case it seems that the VT-d implementation in bhyve will work
fine with ARI enabled devices.

best
Neel

>> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"