From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EF372C3DA4A for ; Wed, 14 Aug 2024 09:59:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XNPiYAxD0nXeda3XoGkXcfBa5gPOVQX7S7Zbc6+r9Yg=; b=GnJZ1dXCe80nHneJxYIxnghzIk jvuA3jX3UYAnVa8IddeFmLPyKL5nLTdlz0KJ4QB8cqco/zmbB2ADWcJ6YnRdbg/HjVDXcUOyH46Sy M02+ECTKcLTsgNwDbMzj9+9paxnk585gyKS+2Yq7RQwplO5KkM5zliBB3q/DmuxmuJzcjF5oDuM1Q mR3gWJU2ZSC29JCf3pZVFoFMpG86BUuOaCKApp3y4ogt75VklFMqNYTD6Pe594BJlyYkwRhAH364d yAsmacKP4cWzfJFvYieXCJJFeJmMRG8RmF7q9gksVQ2UEb//zReW7e+m7XtSj/WdD/JtD1MQhCTfQ 4qqzRjNA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seAmK-00000006Tl4-3YnK; Wed, 14 Aug 2024 09:58:52 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seAlj-00000006Tbl-1jYr for linux-arm-kernel@bombadil.infradead.org; Wed, 14 Aug 2024 09:58:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=XNPiYAxD0nXeda3XoGkXcfBa5gPOVQX7S7Zbc6+r9Yg=; b=kmcMQ/I+3pRp3m//9WgPsMdmiL 2EsBmG9fm3a7XddCDtIv/jQOkVJaI2EjMk58RpsDJARQoLq1DEb0MfqZueaqLYEAko/KSIxDB5q0t 7qMsbuXuaaxAf3SuH1OWSlplTd/Aefb98OT0f3/l95q4zpHrP8FwO1evyMfscIzIVbAfOFloWimym zb2+76F3gqE0z0yfPOw7VRtnQ56guYJGdnpA9/DHaUPog9WtcVPgPR2Dsa6x0z4QGq+bnge5XSmII Qew9mNNt61VkIFNyRd8mXprBkXlrCFXOMqVF5b86vvZb+gFlSbE89yB4LnZH9a8RNEKkSAI/C9GE/ wfAqpqZg==; Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by desiato.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seAlf-000000080zp-3T6v for linux-arm-kernel@lists.infradead.org; Wed, 14 Aug 2024 09:58:14 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5b9fe5ea355so5779a12.0 for ; Wed, 14 Aug 2024 02:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723629485; x=1724234285; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=XNPiYAxD0nXeda3XoGkXcfBa5gPOVQX7S7Zbc6+r9Yg=; b=fxCzJ/a88k/6XKb8pKq9+nYNs88SuZKLiPmrxN2DH6ly6q6I6N90x0Om0vKAqjDd9s aYUpQSaikcMhxmQencnPJ78XYdptVwGCOB4rx+Pg2HwNtzFYvx+INHjKXNEil7JUyNEi 3Ea0Yw26ISZ3TLJYHB5LELlirhRuLBwkslnl5lDYJsvMOD6wLKe520Fn3lVgmiTkbTwc /eoTdo/uqOFQg9rundEtuMmC6BvPfwtHo8XidZQ5ZmQia/Otlcwl8wd/cUHF2tql7Gzh ryLa00tROcXMPqZ1QlxB5aLiK0oADKgT/sr/LmHqbM29pjWVx9P8R/WvqexlwKCR0vC+ 9vig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723629485; x=1724234285; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XNPiYAxD0nXeda3XoGkXcfBa5gPOVQX7S7Zbc6+r9Yg=; b=FunLbYom5sFKXcKRpECbWrvHL9kp+VU/b1PreX6yBtl153MlDTPAa1v3TJvFI9tQoM t5PZ/e+ec8oOneesiGC9ielvkGToBXc4Tq4X8H+NT5GvIRSQJ39lwDWa3Kt1W3ydCxWv uey7zZEtsKqHgAPOxGiCoiWDbdOAgE9Eq3MHWi5i7IVYrLhEQMnjvKSqIw0tFQvHY+zt CGpcDx+XvkMkKG/UlM3+wEp07FGWmZW9dRgiK0QTRS63dEaaZcT4Xc3mWxr72kfjsLtH sL3TgVRKc8IN0wz1nOODEqBq7v7xyMbARSGU/fY+YJ/4sM4fzJsj5apFHwrFlUFPShAt vRIw== X-Forwarded-Encrypted: i=1; AJvYcCW9YqO3rf8a45QsGwt8c5gYDxsJCEKVQOt5H2cfjyUbpsme3UmOBPVgsteWB9dx1J8S2mG3DTeU6ba0mFKWkf1+lTRc9KeHTCEsEg3kJccJTh3Cqxg= X-Gm-Message-State: AOJu0YwU0bnwugZlSOMYnNuWokrl4anxQCX37UZsSiUkMGnFA1N1j/90 NNAvVaHl96WK5jd6MR/yr8ljykyeNKHjnzVgePUHhb2cHIsLdfqMhuz4r1jDRg== X-Google-Smtp-Source: AGHT+IGOoeQSGPXnP0Clm+mJgyY7hA8NUckb53WhjJatTU+/3rVRLEqRqMqPYgosUnSxt0miWa/RPg== X-Received: by 2002:a05:6402:3481:b0:5aa:19b1:ffc7 with SMTP id 4fb4d7f45d1cf-5bea28067bdmr77383a12.2.1723629485134; Wed, 14 Aug 2024 02:58:05 -0700 (PDT) Received: from google.com (203.75.199.104.bc.googleusercontent.com. [104.199.75.203]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429ded31c5esm14718735e9.13.2024.08.14.02.58.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2024 02:58:04 -0700 (PDT) Date: Wed, 14 Aug 2024 09:58:00 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, robin.murphy@arm.com, joro@8bytes.org, nicolinc@nvidia.com, mshavit@google.com Subject: Re: [PATCH 2/2] iommu/arm-smmu-v3: Report stalled S2 events Message-ID: References: <20240812205255.97781-1-smostafa@google.com> <20240812205255.97781-3-smostafa@google.com> <20240813175155.GN1985367@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240813175155.GN1985367@ziepe.ca> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240814_105812_099224_D8AF0A6D X-CRM114-Status: GOOD ( 41.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 13, 2024 at 02:51:55PM -0300, Jason Gunthorpe wrote: > On Mon, Aug 12, 2024 at 08:52:55PM +0000, Mostafa Saleh wrote: > > Previously, S2 stall was disabled and in case there was an event it > > wouldn't be reported on the assumption that it's always pinned by VFIO. > > > > However, now since we can enable stall, devices that use S2 outside > > VFIO should be able to report the stalls similar to S1. > > > > Also, to keep the old behaviour were S2 events from nested domains were > > not reported as they are pinned (from VFIO) add a new flag to track this. > > I'm not entirely clear on every detail of this stall feature... > > But from a core perspective device fault reporting should only ever be > turned on in the STE/CD if the attached domain->iopf_handler is not NULL. > > If it is NULL then any access to a non-present address should trigger > some kind of device error failure automatically. > > This is new core functionality since this code would have been > originally written. Now it is all handled transparently by the core > code. The driver should just deliver all fault events to > iommu_report_device_fault() and it will sort it out. > I agree, as there is no iopf handler in this case, we should just report it to the iommu code and it will reject it instead of tracking this in the driver. And as all the “enable_nesting” stuff is going away soon anyway it’s not worth adding extra code for it. (plus we shouldn’t really assume the intention of caller) > > Signed-off-by: Mostafa Saleh > > --- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 18 +++++++++++++----- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 ++ > > 2 files changed, 15 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > index 8d573d9ca93c..ffa865529d73 100644 > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > @@ -1733,6 +1733,7 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) > > u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]); > > struct iopf_fault fault_evt = { }; > > struct iommu_fault *flt = &fault_evt.fault; > > + struct arm_smmu_domain *smmu_domain; > > > > switch (FIELD_GET(EVTQ_0_ID, evt[0])) { > > case EVT_ID_TRANSLATION_FAULT: > > @@ -1744,10 +1745,6 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) > > return -EOPNOTSUPP; > > } > > > > - /* Stage-2 is always pinned at the moment */ > > - if (evt[1] & EVTQ_1_S2) > > - return -EFAULT; > > - > > This makes sense at first blush since the domain mode shouldn't define > if events should be processed or not, and the events should be failed > anyhow right? If someone did turn on fault reporting in the STE then > it should always be processed to conclusion. > > > if (!(evt[1] & EVTQ_1_STALL)) > > return -EOPNOTSUPP; > > > > @@ -1782,6 +1779,15 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt) > > goto out_unlock; > > } > > > > + /* It is guaranteed that smmu_domain exists as EVTQ_1_STALL is checked. */ > > + smmu_domain = to_smmu_domain(iommu_get_domain_for_dev(master->dev)); > > Strongly discouraging drivers from calling iommu_get_domain_for_dev() > in async paths like this. The locking is tricky and the core code does... > > > + /* nesting domain is always pinned at the moment */ > > + if (smmu_domain->enable_nesting) { > > This is not necessary - a nesting domain will never have an > iopf_handler set. > > It immediately calls iommu_report_device_fault() which will reject it > because of: > > if (!group->attach_handle->domain->iopf_handler) > goto err_abort; > > Which after the rework will end up in find_fault_handler() at the top > of the function: > > https://lore.kernel.org/r/ZrTNGepJXbmfuKBK@google.com > > So I think these parts are not necessary. Yes, I will remove this patch and squash the removal of ignoring S2 events. Thanks, Mostafa > > Though arguably we should be rejecting domains with iopf_handler set > in some of the attach calls.. > > Jason