Date: Fri, 14 Mar 2014 22:06:12 -0400 From: Ryan Stone <rysto32@gmail.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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. The other main change affects pci configuration space accesses. When pcib_read_config/pcib_write_config is called on a downstream port that has ARI enabled, we convert the 8-bit function number back into a 5-bit slot number and 3-bit function number before passing the request up the device tree. This was the simplest way to insulate the rest of the PCI subsystem from knowledge of ARI. I have also added a new tunable, hw.pci.enable_ari, that controls whether ARI will be enabled on devices that support it. I plan on defaulting it to 1 on HEAD but will probably default to 0 when I MFC. I've tested on a few different motherboards at $WORK, but the only ARI-capable device that I have access to is Intel 82599 NICs (ixgbe driver), so if anybody is able to test with other hardware that would be really helpful. Testing that the driver is able to attach and testing basic functionality (e.g. ping on a network interface) would be sufficient. In order for ARI to be enabled both the downstream port (the physical PCIe slot) and the endpoint device (the PCIe card) have to both support ARI. My patch adds support to pciconf -lc to have it print whether a downstream port supports ARI. You can check for ARI support by looking for: cap 10[90] = PCI-Express 2 root port slot max data 128(256) link x0(x4) speed 0.0(5.0) ASPM disabled(L0s/L1) ARI disabled If it says "ARI enabled" or "ARI disabled" then the port supports ARI. If ARI is disabled please confirm that no ARI-capable device is in the slot (or else it's a bug and please report it). If ARI is enabled then please confirm that there is an ARI-capable device in the slot (otherwise please report it to me) pciconf -lc already will print out if a endpoint device supports ARI. Look for the ARI extended capability: ecap 000e[150] = ARI 1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog>