Date: Sun, 16 Mar 2014 23:03:52 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ryan Stone <rysto32@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140316210352.GB21331@kib.kiev.ua> In-Reply-To: <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com> References: <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com> <20140316141216.GA21331@kib.kiev.ua> <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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@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. >=20 > 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. >=20 > 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. >=20 > > From other minor notes, having additional line for "ARI enabled" > > message under bootverbose would make already excessive PCI config > > dump even more problematic. >=20 > 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. --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTJhG3AAoJEJDCuSvBvK1BMNkQAIreZSfturnisdhh1GOnGYyv Uu8JQBUOzCivPm98akiZa4p2b3TfyOtC1piXeEhKkP0eXj1yxcWusnVjX4kqj2Y9 4alTbA3gATLRUhywK74hHa6glsmKIYy5/sMkO1MtvkOPux9simo/Uv6WZjjyKmNV cKeUlA392xCFD+HJnvHvmxYh7VoCfZvVanMK5H3ZRP0GZHpZV8DsrLl2Ww8WJm+m hyQIN3+Pql4Fgsx8iz6tUfUizgij1u03ux181ShFCKXpAQqMGDp7wexyRsfVloNM 8EFRoJeGjM7mPNr2Fi9YsRXQpMaIzt2MTe4PtUtYqXSLKsK8UZSdxN6A7PW7dpK0 V8DIXJZItMtjh4iocGn4pHNyjXSjS68pzb3lYqfvWhW+XlOTu3KgaCZys2fvb0Iv dNZ2j0WIoKbP6HvXsaPIWYZwcTceM42nleZFmEhkUUbpYAv+YwmRzW9DujW767iK dXXLG/SLj9MBkWJDkDTnyNA1f42BGX1PfJgddqxIrsiigbe8KXCO5vHisrLQgTzg xB6Smv4ilvBkCG0Ed8ouuMsFzranTswlvRRKQa6RbE+iechueg97+7C4OoEBflXW dP0lBnIz+lkSyExOm58fk0iyGHqLFyFjGbeCzmFyC8cn9LfUVve9O0bZmDSjNYKF Xgdp6RohFvNV/3QYjWlf =8XT7 -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140316210352.GB21331>