linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Mostafa Saleh <smostafa@google.com>
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
Date: Tue, 13 Aug 2024 14:51:55 -0300	[thread overview]
Message-ID: <20240813175155.GN1985367@ziepe.ca> (raw)
In-Reply-To: <20240812205255.97781-3-smostafa@google.com>

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.

> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
>  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.

Though arguably we should be rejecting domains with iopf_handler set
in some of the attach calls..

Jason


  parent reply	other threads:[~2024-08-13 17:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-12 20:52 [PATCH 0/2] Fix handling of S2 stalls Mostafa Saleh
2024-08-12 20:52 ` [PATCH 1/2] iommu/arm-smmu-v3: Match Stall behaviour for S2 Mostafa Saleh
2024-08-13 11:46   ` Robin Murphy
2024-08-13 13:40     ` Mostafa Saleh
2024-08-13 17:01   ` Jason Gunthorpe
2024-08-12 20:52 ` [PATCH 2/2] iommu/arm-smmu-v3: Report stalled S2 events Mostafa Saleh
2024-08-13 11:57   ` Robin Murphy
2024-08-13 13:43     ` Mostafa Saleh
2024-08-13 17:51   ` Jason Gunthorpe [this message]
2024-08-14  9:58     ` Mostafa Saleh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240813175155.GN1985367@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mshavit@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).