From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 14:12:27 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70684BA6 for ; Sun, 16 Mar 2014 14:12:27 +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 E2FE7CA6 for ; Sun, 16 Mar 2014 14:12:26 +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 s2GECHjg057777; Sun, 16 Mar 2014 16:12:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2GECHjg057777 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2GECHAm057776; Sun, 16 Mar 2014 16:12:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Mar 2014 16:12:17 +0200 From: Konstantin Belousov To: Ryan Stone Subject: Re: [PATCH] Support PCIe Alternative RID Interpretation (ARI) Message-ID: <20140316141216.GA21331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" 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" 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: Sun, 16 Mar 2014 14:12:27 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 14, 2014 at 10:06:12PM -0400, Ryan Stone wrote: > http://people.freebsd.org/~rstone/patches/pci_ari.diff >=20 > 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. >=20 > 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. =46rom other minor notes, having additional line for "ARI enabled" message under bootverbose would make already excessive PCI config dump even more problematic. --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTJbFAAAoJEJDCuSvBvK1BkroP+wZ/m5Zcoje1tR7SFjmD8VPy 9HoPZwVQVWQmAmgGkqXm6YP7naP3FjP/E5qYoWhBfO335eTJTaTnmLt+1ClcjD3Q zE1xfVajulQsi1/1q9mPt4rbN6TrVMmP9Qb/r8ClLdGH0VQZW550UuWuY7dlafV3 HXzuWSmKS18DdJ1bJgyNX7kyu0VgCEjVoDKiPJSCuiHp+VKRBjT8L6Zgar0N2W3q FfSxbcoqVwzgVbP61xjL/A/3oeXeNqvE8khoDpYN2nDBpLL7zPAQ4XOBdxlvKR80 CBXNlCN9Mua5LboezdZVuGwsIECcGSnT08oBKLWsKL+y/A273iHk+mN0aWJnaOc8 vIaI9dlw+zEAzBoVEwOY9+a9WH0ijMWoZPUTTrtsxqolM3fJLlL7am5hsv/IYR9m vlInpTt7LxQNSVUEgKo5fZpaCZMyw8PVT0/FSOMekVQTTlvuhlfcvksOYRsz44eW iRXfOeFDI679NHP3ar/NJmF4JXbZ2r+ILg4QrOdXU0MBSBfSIBKETOU+8eYQA1Xh 5Jpo0RjQCoLvuK1fHG10pNw3SLrDjj7qBCG83s5YNszZPRzD+QoB/+Oh3PhfAGYy maAnUlRRrS3+fgHCg6lEF5g8SslFRSxXG9fc5NfIq9D5Px5tGZ5eMpQyCoO28QL8 klXCEODgpQPWB1zcRM0D =56wQ -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM--