Date: Tue, 25 Mar 2014 23:13:55 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ryan Stone <rysto32@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Neel Natu <neelnatu@gmail.com> Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140325211355.GG21331@kib.kiev.ua> In-Reply-To: <CAFMmRNxM1E2aNtZV588V3BGkz1aOaGgAXGbgktYrmzT9M3EyVw@mail.gmail.com> References: <CAFMmRNzL3uBZ-djWgpnKi3XDQdq4c1ODAL_8E-Vpy-dPLa-hog@mail.gmail.com> <20140316141216.GA21331@kib.kiev.ua> <CAFMmRNwormaaPXk6rJ-JJGePS6fDNFsdKAfmmW2jGLNRscf1Pw@mail.gmail.com> <CAFgRE9F632zLseG7MobxgV5CdvD0KyMn28CBSwYqVtZKuLBwRw@mail.gmail.com> <CAFMmRNwCGVhyn5cU29YpsVq44Q5i51C38GVsz33xGeqNyemx0Q@mail.gmail.com> <20140319140236.GM21331@kib.kiev.ua> <CAFMmRNxM1E2aNtZV588V3BGkz1aOaGgAXGbgktYrmzT9M3EyVw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--TALVG7vV++YnpwZG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 24, 2014 at 03:34:21PM -0400, Ryan Stone wrote: > On Wed, Mar 19, 2014 at 10:02 AM, Konstantin Belousov > <kostikbel@gmail.com> wrote: > > I do not like this, in fact. Not the general idea, but the implementat= ion. > > I think that what is needed is method which would return combined > > slot/function number (or just function number for ARI-enabled device). > > Then, existing pci_get_bus() and this new method are enough for proper > > construction of the translating structures. >=20 > I disagree with this approach. I think that the interface that you > envision is too specific to the needs of the DMAR code. This idea of > a "half RID" really only exists in the VT-d spec. I have some more > work forthcoming (for which ARI is a requirement) where I need to > access the full RID: when PCI SR-IOV is used to instantiate virtual > PCI functions(VFs), the VFs appear on the PCI tree at a specified > offset from the RID of the parent physical device. That offset is > definitely not guaranteed to be < 255 (in other words, the VFs might > appear at a different bus number from the parent). The current code > that I have to deal with this knows way too much about the details of > how to decode RIDs, including the possibility of ARI. Writing it in > terms of an interface like pci_get_rid() should simplify it nicely and > help localize the knowledge of ARI to the pcib driver. Well, either the interface I described is provided by pci core, or iommu has to de-facto implement it itself. IMO it is clearer to have it in pci, but I do not want to block your work on this. >=20 > > Again, I do not like this. IMO the patch is too conservative. > > Almost all occurences of the s/f in the IOMMU code must be removed, > > and replaced by the half-rid returned by the new method from above. > > In particular, context must be stripped of s/f at all. >=20 > Originally I was going to remove all references to slot and function > in the DMAR code. However what I found was that there are a number of > places that want to print the pci bus/slot/func for debugging > purposes. In those places printing out the RID is a lot less user > friendly, so I left the slot and func members in the context for this > purpose. I wasn't entirely happy with this either to be honest. I mean, that slot and func should be obtained using pci accessors where needed. It is definitely not perf-critical, and I dislike having both bsf and rid in the context structure more, then using accessors. --TALVG7vV++YnpwZG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTMfGSAAoJEJDCuSvBvK1B5H8QAJXJg5+/ZpljiKm+mUZmc4hL iVzJKmYKzNIbU+wjRMXGnV0qFXSDS2ILV+UfLzPD2j+J5M2sZaP7cbnS1Oa05XQ/ N6oDGHuslPiSrcZphfoD6DEofxl4Ts3Q5iOsQaFT4pBja5Ahddya0wrfE3r2AJni TYZhTxLOvvwlHr6Xt2q+Pg0Fn2E23YASAn2yJauxFcrd7ZkSUFtK2qGhVWfMfapZ BGNqaUtzPx3y5VRHQfzu11ZrYFdP+zMnO9kSpa4JO5gKLAxTJto1DrKNKWDs5MHh 5ozISgkqiEdOm3zb0Ta5aATESOrK41TUIYrLfTMhds7amd1CPPa+JEUN1cJrNrGx wcNpIvQ2t+bmAuPEg42E5zOhmjKxZ+H84r1shGFC5mq2XS5+vy47tROtJLgstZ3n aatSAdHBtaGsqw48O6th5iaz99xRd1lixYsDPrS2HZJKzBE1zWro4LzT8penCzwV 3ZwrXFBMATffo/dwjbyvzUN0CJcAd4S1HnAZRMbqwqftuDPIL9B2+HWR7bdGpDcW 5DnhLnkqbLrSiBVFGYTiCHF3/g6X8GD13qnyxv7V2t12bZfuIDnF+Ho9FqJkBGKy 2LyV4Nwftv5/FFhm6oTCl3VYFmq56oVsS+zDbjgSWqZgdVA4CPnfl/9deJgGYp+v SXaRhAbtawam3dbO6Oxk =F6Jv -----END PGP SIGNATURE----- --TALVG7vV++YnpwZG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140325211355.GG21331>