Message ID | 20230922-iommu-type-regression-v1-1-1ed3825b2c38@marcan.st |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5726157vqi; Fri, 22 Sep 2023 09:49:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFlysKCBN0G36Bpu/6auLIxeIrn8UqFoYCfj1tDbOf0lSVTJxAQvlMqYziR+2mwRQTH51x7 X-Received: by 2002:a05:6a00:84e:b0:68e:496a:7854 with SMTP id q14-20020a056a00084e00b0068e496a7854mr9412984pfk.18.1695401368391; Fri, 22 Sep 2023 09:49:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695401368; cv=none; d=google.com; s=arc-20160816; b=GFox3pAzDxrWvlrt9e75SrGchKKbfG1azu22DnN69u2nnQvN/zgyiGf/1g2BmOXPHN fAOd+qN9gvu7MazFSvKbcKV+/eO/auz50ZB8NGQSH/YyeB1Q4dOLBifM3x0jbv1cEjLj k2KjximB9tIoUUvttrZfRFaFLWPhUmZMM9gXzwaHsqLTLTJGLOFHPum1K63iCP36P9tL 7Bz+hlXCBYEmYh1W5Rki2x3bNAyQgcxhVgkRX75yDeq0mq0G8Xvu+BQHBozK1E4hFaoF n79i9KTjH/JalU82HV0ndV65ygmpiP/wroPkyqetSUxlN81KED9E7mW7g1HZ6tl/0TsN aLdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=94ZRtK7UsqgTiZEXP2UQItCaVrUz4q/TnOTVUx8jPfc=; fh=KuXNZ1l7eHdfBxEBKH05eMMA7pDfwEFyOMwOaNmX6rc=; b=uWIkWF33Fdr75DH5U5hjN3KMSxMx27U/EWbDWClSUhV33FusXBdCzevut1ey145w8K LZ5DpAzwnoOlE1dHs4+oV8/lCj0KH9saL8EBSOVq1s0XR3ErsBAaG+6QaR2aOwdkWCOF RbZcCAZawhQJmLZASXm5uFkJbonhwr4ZRfeuZq6zFigCfo40dyQ7O0dP40xP/rb0RN6J j2xNKDQmmufcY/v7j2BQPOv8oKiLqDZea/UkvtlIqoNYBXeMknFLrxSZwoPSAktC7qsF CUPUrTjTzU9fMTX1VO5jrNoNcAuIzt23WTjyoZ0Pylx+9UJH3akUuCdOOtH7vKNU4beQ S8bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=EL+kQP6z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id bq26-20020a056a000e1a00b006826c8d5a31si4129515pfb.21.2023.09.22.09.49.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 09:49:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=EL+kQP6z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 141AD8399768; Fri, 22 Sep 2023 06:48:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234187AbjIVNsN (ORCPT <rfc822;chrisfriedt@gmail.com> + 29 others); Fri, 22 Sep 2023 09:48:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234147AbjIVNsM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 22 Sep 2023 09:48:12 -0400 X-Greylist: delayed 447 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 22 Sep 2023 06:48:05 PDT Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4FCD92; Fri, 22 Sep 2023 06:48:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: sendonly@marcansoft.com) by mail.marcansoft.com (Postfix) with ESMTPSA id E9BE24203C; Fri, 22 Sep 2023 13:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1695390035; bh=wnRMaJBOS2DBNUxEtrGxJj6grzGED1qsQnxvwl3853Q=; h=From:Date:Subject:To:Cc; b=EL+kQP6z2D1r/FcD1TXdu49qUlyYgYgj0amx/V7WZ9ABEa/REXdo+1rVGrP5gIKpu geBzkpMjccNNO5cAGwX2nbtGyBjoKy0G5FwgpoB5xobEZXQdtOe4vKBrZLUavK08HW cxRQAeVZdV2m+EYqL0bjS3NA7Gx6HxP6jFJuxVMLBGyCsm8TtvhygKKpF+bi49b166 4uC99oKwrAvYnU20loGtw829HDNtfL3B/s8vNfiSEgQLcGJsg+7mTo/gTrDZpa+Gaq y4U7QZohJ04few8TmHtIC1vkcmc1HvG3dD6Hs2nOw42BMUobiKs9v5wkoPn7dhvDlS gG8UbmaElcWNw== From: Hector Martin <marcan@marcan.st> Date: Fri, 22 Sep 2023 22:40:20 +0900 Subject: [PATCH REGRESSION] iommu: Only allocate FQ domains for IOMMUs that support them MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230922-iommu-type-regression-v1-1-1ed3825b2c38@marcan.st> X-B4-Tracking: v=1; b=H4sIAEOZDWUC/x3Myw5AQAxA0V+RrjUZRYRfEQuPDl14pIOQiX83L O/iXA+OVdhBFXlQPsXJuoRI4gj6qV1GRhlCAxlKTUmEss7zgfu9MSqPyu4TSHmX2SwdbFEYCHZ TtnL937p5nhd8EatbZwAAAA== To: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Jason Gunthorpe <jgg@ziepe.ca>, Jerry Snitselaar <jsnitsel@redhat.com> Cc: Joerg Roedel <jroedel@suse.de>, Neal Gompa <neal@gompa.dev>, "Justin M. Forbes" <jforbes@fedoraproject.org>, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, stable@vger.kernel.org, regressions@lists.linux.dev, Hector Martin <marcan@marcan.st> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1654; i=marcan@marcan.st; h=from:subject:message-id; bh=wnRMaJBOS2DBNUxEtrGxJj6grzGED1qsQnxvwl3853Q=; b=owGbwMvMwCUm+yP4NEe/cRLjabUkhlTemf6MGpdr17EecAmcefbUi4gtXz2fGH8+UWdeZCSzT uqnx3arjlIWBjEuBlkxRZbGE72nuj2nn1NXTZkOM4eVCWQIAxenAEyk4gvDT8bEBMkPJ67IfVtn yV+s31PwoTNX+83atU/P8m3g375coYeRoX/Oi7b2+oKDy0Sr3eZP3Hw85t/sV/OsFJfeuW7EPyn HgRkA X-Developer-Key: i=marcan@marcan.st; a=openpgp; fpr=FC18F00317968B7BE86201CBE22A629A4C515DD5 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Fri, 22 Sep 2023 06:48:23 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777748971168252805 X-GMAIL-MSGID: 1777757185242244729 |
Series |
[REGRESSION] iommu: Only allocate FQ domains for IOMMUs that support them
|
|
Commit Message
Hector Martin
Sept. 22, 2023, 1:40 p.m. UTC
Commit a4fdd9762272 ("iommu: Use flush queue capability") hid the
IOMMU_DOMAIN_DMA_FQ domain type from domain allocation. A check was
introduced in iommu_dma_init_domain() to fall back if not supported, but
this check runs too late: by that point, devices have been attached to
the IOMMU, and the IOMMU driver might not expect FQ domains at
ops->attach_dev() time.
Ensure that we immediately clamp FQ domains to plain DMA if not
supported by the driver at device attach time, not later.
This regressed apple-dart in v6.5.
Cc: regressions@lists.linux.dev
Cc: stable@vger.kernel.org
Fixes: a4fdd9762272 ("iommu: Use flush queue capability")
Signed-off-by: Hector Martin <marcan@marcan.st>
---
drivers/iommu/iommu.c | 9 +++++++++
1 file changed, 9 insertions(+)
---
base-commit: ce9ecca0238b140b88f43859b211c9fdfd8e5b70
change-id: 20230922-iommu-type-regression-25b4f43df770
Best regards,
Comments
On 22/09/2023 23.21, Robin Murphy wrote: > On 22/09/2023 2:40 pm, Hector Martin wrote: >> Commit a4fdd9762272 ("iommu: Use flush queue capability") hid the >> IOMMU_DOMAIN_DMA_FQ domain type from domain allocation. A check was >> introduced in iommu_dma_init_domain() to fall back if not supported, but >> this check runs too late: by that point, devices have been attached to >> the IOMMU, and the IOMMU driver might not expect FQ domains at >> ops->attach_dev() time. >> >> Ensure that we immediately clamp FQ domains to plain DMA if not >> supported by the driver at device attach time, not later. >> >> This regressed apple-dart in v6.5. > > Apologies, I missed that apple-dart was doing something unusual here. > However, could we just fix that directly instead? > > diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c > index 2082081402d3..0b8927508427 100644 > --- a/drivers/iommu/apple-dart.c > +++ b/drivers/iommu/apple-dart.c > @@ -671,8 +671,7 @@ static int apple_dart_attach_dev(struct iommu_domain > *domain, > return ret; > > switch (domain->type) { > - case IOMMU_DOMAIN_DMA: > - case IOMMU_DOMAIN_UNMANAGED: > + default: > ret = apple_dart_domain_add_streams(dart_domain, cfg); > if (ret) > return ret; > > > That's pretty much where we're headed with the domain_alloc_paging > redesign anyway - at the driver level, operations on a paging domain > should not need to know about the higher-level usage intent of that > domain. Ideally, blocking and identity domains should have their own > distinct ops now as well, but that might be a bit too big a change for > an immediate fix here. Sure, but it sounded like if there's a capability for this the core should probably use it and not expose the type at all to drivers that can't support it :) If you think defaulting to that branch in DART is correctly future-proof I can make that change. It's not the only driver checking the domain type in attach_dev(), but it might be the only one enumerating all the options instead of checking for specific cases only (e.g. intel checks for IOMMU_DOMAIN_IDENTITY). - Hector
On Fri, Sep 22, 2023 at 03:21:17PM +0100, Robin Murphy wrote: > On 22/09/2023 2:40 pm, Hector Martin wrote: > > Commit a4fdd9762272 ("iommu: Use flush queue capability") hid the > > IOMMU_DOMAIN_DMA_FQ domain type from domain allocation. A check was > > introduced in iommu_dma_init_domain() to fall back if not supported, but > > this check runs too late: by that point, devices have been attached to > > the IOMMU, and the IOMMU driver might not expect FQ domains at > > ops->attach_dev() time. > > > > Ensure that we immediately clamp FQ domains to plain DMA if not > > supported by the driver at device attach time, not later. > > > > This regressed apple-dart in v6.5. > > Apologies, I missed that apple-dart was doing something unusual here. > However, could we just fix that directly instead? > > diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c > index 2082081402d3..0b8927508427 100644 > --- a/drivers/iommu/apple-dart.c > +++ b/drivers/iommu/apple-dart.c > @@ -671,8 +671,7 @@ static int apple_dart_attach_dev(struct iommu_domain > *domain, > return ret; > > switch (domain->type) { > - case IOMMU_DOMAIN_DMA: > - case IOMMU_DOMAIN_UNMANAGED: > + default: > ret = apple_dart_domain_add_streams(dart_domain, cfg); > if (ret) > return ret; Yes, I much prefer this to the original patch please. Drivers should not be testing DMA_FQ at all. I already wrote a series to convert DART to domain_alloc_paging() that fixes this inadvertantly. Robin's suggestion is good for a temporary -rc fix. Removing the switch is slightly more robust: if (domain->type & domain->type & __IOMMU_DOMAIN_PAGING) { [..] return 0 } if (domain->type == IOMMU_DOMAIN_BLOCKED) { .. } return -EOPNOTSUPP; But not so worthwhile since I deleted all this anyhow... I'll send out the dart series, it can't go to -rc, so a patch is still needed. Thanks, Jason
Linux regression tracking (Thorsten Leemhuis)
Sept. 24, 2023, 7:49 a.m. UTC |
#3
Addressed
Unaddressed
[TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 22.09.23 15:40, Hector Martin wrote: > Commit a4fdd9762272 ("iommu: Use flush queue capability") hid the > IOMMU_DOMAIN_DMA_FQ domain type from domain allocation. A check was > introduced in iommu_dma_init_domain() to fall back if not supported, but > this check runs too late: by that point, devices have been attached to > the IOMMU, and the IOMMU driver might not expect FQ domains at > ops->attach_dev() time. > > Ensure that we immediately clamp FQ domains to plain DMA if not > supported by the driver at device attach time, not later. > > This regressed apple-dart in v6.5. > [...] Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced a4fdd9762272 #regzbot title iommu: apple-dart regressed #regzbot monitor: https://lore.kernel.org/all/20230922-iommu-type-regression-v2-1-689b2ba9b673@marcan.st/ #regzbot fix: iommu/apple-dart: Handle DMA_FQ domains in attach_dev() #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 3bfc56df4f78..12464eaa8d91 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -2039,6 +2039,15 @@ static int __iommu_attach_device(struct iommu_domain *domain, if (unlikely(domain->ops->attach_dev == NULL)) return -ENODEV; + /* + * Ensure we do not try to attach devices to FQ domains if the + * IOMMU does not support them. We can safely fall back to + * non-FQ. + */ + if (domain->type == IOMMU_DOMAIN_DMA_FQ && + !device_iommu_capable(dev, IOMMU_CAP_DEFERRED_FLUSH)) + domain->type = IOMMU_DOMAIN_DMA; + ret = domain->ops->attach_dev(domain, dev); if (ret) return ret;