[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 3/3] AMD/IOMMU: iommu_enable vs iommu_intremap


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 25 Oct 2021 12:28:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jVjYceLCBK5cDUZH41XgQndwcnXLlc4EB6C4hRmB6Qw=; b=FCeOfvv/iK5jfnIFdtO08pRrA3Fzj5R0KJYNvdKkTBzV6Rk6difQmBQlasDvutT2UltUaHWlN+nUPB23aHba2IhzDA/5wgdo83CN8Dfzc530LotP95MZrW7cjPDf9bUbDO2199JAVHQI2us+eadlYM7nrFQV4LKz78kjd5U11jcWeUT3YKEALejbGOWMpfISUYvNGaPYaqJAwtoLaDCBg3+yMThyle1lBoUCC07gbGi/aGbuZZJGbl2Jjs/r7uZO36Ngz/lG0F0VRSUtDl1ZMhlwiGnvrsJOyxi6pdbm9lFnkjC2EhVn2A5Loef3Prd+pEOrkk3pSCQ5qXxvyAbswQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fykzw09+ShlFS34wtNIzZRAe+kNVWIMdNCw1XsRg4TtXAIN4PhiXQl1QEE2nbIOg/JS4hDDZXvwWt1I00jAv1xd4WnImAVtWaJHEYBdheMRybHondF1sJWViFYctcPSe2Xvam4hnfN1Ize1Q3BCyaN093KAcpdB7V031EYPzp3jSy3v5hRauuqmXMsSn5I2TTD5gYL8Cw8VDY9bo/HUhcEe3XzPNDMRmY8+goxS4bNMKuFbjKsZnyKRcECdqLx+4GXxi/m97d61gZGI85S+8D5SeoOrmTNQvWi4VOQI51r3T5Kr8sIs1GP9RhzQmvG+5z1JTvS++C9LL8ti5/59gbA==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Mon, 25 Oct 2021 10:28:43 +0000
  • Ironport-data: A9a23:VB2lKKspjjWsjbDtRywVs1d6JufnVLRZMUV32f8akzHdYApBsoF/q tZmKTuAOq2DZjT3fNwkOom0p0gB7ZXTzd4wGwE5+SA3RH5H+JbJXdiXEBz9bniYRiHhoOOLz Cm8hv3odp1coqr0/0/1WlTZQP0VOZigHtIQMsadUsxKbVIiGHhJZS5LwbZj29cw24ThWWthh PupyyHhEA79s9JLGjp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMeaFGH/bSe gr25OrRElU1XfsaIojNfr7TKiXmS1NJVOSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ NplkZefclsXBrHwv9tNUCNUKhNzJ/If5+qSSZS/mZT7I0zudnLtx7NlDV0sPJ1e8eFyaY1M3 aVGcnZXNEnF3r/ohuLgIgVvrp1LwM3DJoQQt2sm1TjEJf0nXYrCU+PB4towMDIY250TR6qGO 5BxhTxHNAmaX0JTfXgrFZdhkf/2rEP2XDkItwfAzUYwyzeKl1EguFT3C/LKfvSaSMMTmVyXz kre9nn9KgEXMpqY0zXt2nCmi/LLnCj7cJkPD7D+/flv6HWDy2pWBBAIWF+TpfiillX4S99ZM 1YT+Cclse417kPDczXmd0Tm+jje5EdaAocOVb1hgO2Q9kbKyyKSKVNYcAZdVPsZ5MwMSQUY2 0XWxsy8UFSDr4apYX6a876Vqxa7Ni4UMXIOaEc4cOcV3zXwiNps1kyXH76PBIbw14evQWihn FhmuQBn3+1L5fPnwZlX6rwub9iEnZPOUhIurjveWmao/2uVj6b0OtT2tzA3ARtGRbt1r2VtX lBZw6ByD8hUVPlhcRBhp81WRNmUCw6tamG0vLKWN8BJG86R03CiZ5tMxzp1OV1kNM0JERewP hSO4FsJvs4LZCH6BUOSX25XI556pUQHPY+9Ps04k/IUOsQhHON51Hg2DaJv44wduBd1yvxuU XtqWc2tEWwbGcxaIMmeHI8gPUsQ7nlmnwv7HMmjpzz+iOb2TCPFGN8tbQrVBshkvfzsnekg2 4sGXyd8404EC7OWj+i+2dN7EG3m2lBiVMCo8JQMLbDSSuekcUl4Y8LsLXoaU9UNt4xel/vS/ 2H7XUldyVHlgmbAJxnMYXdmAI4Dl74mxZ7iFSBzb1uuxVY5ZoOjsPUWe5ctJOF1/+1/1/9kC fICfpzYUPhITz3G/RUbbIX889M+JEj621rWMnr3eiU7cr5hWxfNpo3ucDzw+XRcFSGwr8Y// eGtj1uJXZoZSg1+J8/Kc/bznUiptH0QlbsqDUvFK9VeYmv2941uJ3Cjh/M7OZhUex7C2iGbx 0CdBhJB/bvBpIo88d/og6GYrtj2T7siTxQCR2SCtOS4LyjX+Gan0LRsaufQcGCPTn7w9YWje f5Rk6P2PsoYkQsYqIF7Cbtqk/4zvoO9u79Aww14N3zXdFD3WKh4K3yL0MQT5K1AwrhV5Vm/V k6Vo4QIPLyIPIXuEUILJRpjZeOGjKlGlj7X5PUzAUP7+C4oo+bXDRQMZ0GB2H5HMb94EII52 uNw6scZ5ju2hgcuLtvb3Dtf8H6BLyBYXqgq3n3A7FQHVub/Jol+XKHh
  • Ironport-hdrordr: A9a23:rsQMt6qWhlGyS8+4i1wCsOoaV5vNL9V00zEX/kB9WHVpm5Oj+f xGzc516farslossREb+expOMG7MBXhHLpOkPQs1NaZLXPbUQ6TTb2KgrGSpgEIdxeOktK1kJ 0QD5SWa+eAfGSS7/yKmDVQeuxIqLLsndHK9IWuv0uFDzsaEJ2Ihz0JdDpzeXcGPTWua6BJc6 Z1saF81kWdkDksH46GL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC T4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmRsXue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqrneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3Glpn1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfY/hDc5tABCnhk3izytSKITGZAV3Iv7GeDlMhiWt6UkXoJgjpHFogPD2nR87heQAotd/lq P5259T5cNzp/ktHNVA7dc6MLiK41P2MGfx2UKpUBza/fI8SjnwQ6Ce2sRA2AjtQu1P8KcP
  • Ironport-sdr: dp1lQhuESu1f1gcqPbZnKoPGkN7OEfOTtlW3bbdi3EEk7GaTaVqgngHwKGGcimVXykgpYy1trP Wpa6GiVABCmHu4jh6JreCgDHGJX5Go4fi+8fdDyUt8XDwp0iOxzXY15rXz5jsM4jKgAEdIWwKR BJa6Uey9WbRadM3fgZGEGoy0+0p0Snmib1HRIcttkgdz+lV+i1ct7iwz/rHZJXFgJJ7MzU/uK6 iyE1yBmjcp/TqkYHUlvXR0Eef0SwuT3asxGH7yL6rIMUbcEgsm3rWeMTtk6WmCxCH3oeSRfUf2 +JsR+15tNHHNM7QemGVvm8Lh
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Oct 21, 2021 at 11:59:02AM +0200, Jan Beulich wrote:
> The two are really meant to be independent settings; iov_supports_xt()
> using || instead of && was simply wrong. The corrected check is,
> however, redundant, just like the (correct) one in iov_detect(): These
> hook functions are unreachable without acpi_ivrs_init() installing the
> iommu_init_ops pointer, which it does only upon success. (Unlike for
> VT-d there is no late clearing of iommu_enable due to quirks, and any
> possible clearing of iommu_intremap happens only after iov_supports_xt()
> has run.)
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> In fact in iov_detect() it could be iommu_enable alone which gets
> checked, but this felt overly aggressive to me. Instead I'm getting the
> impression that the function may wrongly not get called when "iommu=off"
> but interrupt remapping is in use: We'd not get the interrupt handler
> installed, and hence interrupt remapping related events would never get
> reported. (Same on VT-d, FTAOD.)

I've spend a non-trivial amount of time looking into this before
reading this note. AFAICT you could set iommu=off and still get x2APIC
enabled and relying on interrupt remapping.

> For iov_supports_xt() the question is whether, like VT-d's
> intel_iommu_supports_eim(), it shouldn't rather check iommu_intremap
> alone (in which case it would need to remain a check rather than getting
> converted to ASSERT()).

Hm, no, I don't think so. I think iommu_enable should take precedence
over iommu_intremap, and having iommu_enable == false should force
interrupt remapping to be reported as disabled. Note that disabling it
in iommu_setup is too late, as the APIC initialization will have
already taken place.

It's my reading of the command line parameter documentation that
setting iommu=off should disable all usage of the IOMMU, and that
includes the interrupt remapping support (ie: a user should not need
to set iommu=off,no-intremap)

> ---
> v2: New.
> 
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -731,8 +731,7 @@ bool __init iov_supports_xt(void)
>  {
>      unsigned int apic;
>  
> -    if ( !iommu_enable || !iommu_intremap )
> -        return false;
> +    ASSERT(iommu_enable || iommu_intremap);

I think this should be && in order to match my comments above.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.