From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 21:14:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 063485C5 for ; Tue, 25 Mar 2014 21:14:01 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 805396A5 for ; Tue, 25 Mar 2014 21:14:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2PLDtEW026748; Tue, 25 Mar 2014 23:13:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2PLDtEW026748 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2PLDtgv026747; Tue, 25 Mar 2014 23:13:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Mar 2014 23:13:55 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140325211355.GG21331@kib.kiev.ua> References: <20140316141216.GA21331@kib.kiev.ua> <20140319140236.GM21331@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TALVG7vV++YnpwZG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Neel Natu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:14:01 -0000 --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 > 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--