[PATCH] Support PCIe Alternative RID Interpretation (ARI)
Konstantin Belousov
kostikbel at gmail.com
Sun Mar 16 14:12:27 UTC 2014
On Fri, Mar 14, 2014 at 10:06:12PM -0400, Ryan Stone wrote:
> http://people.freebsd.org/~rstone/patches/pci_ari.diff
>
> This patch add support for PCIe Alternative RID Interpretation (ARI)
> to our PCI implementation. ARI is an optional feature in PCIe; when
> it is enabled on a endpoint device that device can have up to 256 PCI
> functions (increased from 8). This is implemented by re-interpreting
> the 5-bit slot number as being part of the function number. The slot
> number for all such functions will implicitly be 0.
>
> There are two main changes here. The first changes PCI enumeration to
> explicitly probe slot 0, function 0 separate from all other devices.
> This is necessary because we must check whether the device supports
> ARI and enable it before enumerating the rest of the devices.
Am I reading the patch correctly, that device (0, 0, 200) would return
slot 0 and function 200 from pci_get_slot() and pci_get_function() ?
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.
From other minor notes, having additional line for "ARI enabled"
message under bootverbose would make already excessive PCI config
dump even more problematic.
-------------- 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/3a7aa254/attachment.sig>
More information about the freebsd-hackers
mailing list