linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mostafa Saleh <smostafa@google.com>
To: Kunkun Jiang <jiangkunkun@huawei.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>, Jason Gunthorpe <jgg@ziepe.ca>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Michael Shavit <mshavit@google.com>,
	"moderated list:ARM SMMU DRIVERS"
	<linux-arm-kernel@lists.infradead.org>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	wanghaibin.wang@huawei.com, yuzenghui@huawei.com,
	tangnianyao@huawei.com
Subject: Re: [bug report] iommu/arm-smmu-v3: Event cannot be printed in some scenarios
Date: Wed, 24 Jul 2024 09:15:58 +0000	[thread overview]
Message-ID: <ZqDGTnH8TCxEkkEV@google.com> (raw)
In-Reply-To: <6147caf0-b9a0-30ca-795e-a1aa502a5c51@huawei.com>

Hi Kunkun,

On Wed, Jul 24, 2024 at 09:42:09AM +0800, Kunkun Jiang wrote:
> Hi all,
> 
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> 1797                 while (!queue_remove_raw(q, evt)) {
> 1798                         u8 id = FIELD_GET(EVTQ_0_ID, evt[0]);
> 1799
> 1800                         ret = arm_smmu_handle_evt(smmu, evt);
> 1801                         if (!ret || !__ratelimit(&rs))
> 1802                                 continue;
> 1803
> 1804                         dev_info(smmu->dev, "event 0x%02x received:\n",
> id);
> 1805                         for (i = 0; i < ARRAY_SIZE(evt); ++i)
> 1806                                 dev_info(smmu->dev, "\t0x%016llx\n",
> 1807                                          (unsigned long long)evt[i]);
> 1808
> 1809                         cond_resched();
> 1810                 }
> 
> The smmu-v3 driver cannot print event information when "ret" is 0.
> Unfortunately due to commit 3dfa64aecbaf
> ("iommu: Make iommu_report_device_fault() return void"), the default
> return value in arm_smmu_handle_evt() is 0. Maybe a trace should
> be added here?

In my opinion this change should be reverted as it’s very useful to
print event faults (for debugging crashes) as not always tracing is
available and enabled, and as we don’t want to print paging events
we should know if a device handled it or not.

Otherwise, as best effort from the driver, we can only skip printing
for IOPF enabled devices something like this? (or may be use
arm_smmu_master_sva_enabled() as I see only SVA uses it)

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 a31460f9f3d4..57f3a7d0e40f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1777,7 +1777,11 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
 		goto out_unlock;
 	}

-	iommu_report_device_fault(master->dev, &fault_evt);
+	if (master->iopf_enabled)
+		iommu_report_device_fault(master->dev, &fault_evt);
+	else
+		ret = -ENODEV;
+
 out_unlock:
 	mutex_unlock(&smmu->streams_mutex);
 	return ret;

But let’s see what others think.

Thanks,
Mostafa

> 
> Thanks,
> Kunkun Jiang
> 


  reply	other threads:[~2024-07-24  9:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  1:42 [bug report] iommu/arm-smmu-v3: Event cannot be printed in some scenarios Kunkun Jiang
2024-07-24  9:15 ` Mostafa Saleh [this message]
2024-07-24  9:22 ` Kunkun Jiang
2024-07-24 10:24   ` Will Deacon
2024-07-24 13:03     ` Jason Gunthorpe
2024-07-25  7:35       ` Tian, Kevin
2024-07-25 12:58         ` Jason Gunthorpe
2024-07-26  0:04           ` Tian, Kevin
2024-07-29  5:29     ` Baolu Lu
2024-08-02 14:38       ` Pranjal Shrivastava
2024-08-05 12:13         ` Kunkun Jiang
2024-08-05 12:30           ` Will Deacon
     [not found]             ` <ZrDwolC6oXN44coq@google.com>
2024-08-06  0:09               ` Baolu Lu
2024-08-06 12:49               ` Jason Gunthorpe
2024-08-06 15:58                 ` Pranjal Shrivastava
2024-08-07  5:35                   ` Baolu Lu
2024-08-08 13:50                     ` Pranjal Shrivastava
2024-08-13 17:56                       ` Jason Gunthorpe
2024-08-14  9:02                         ` Pranjal Shrivastava

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=ZqDGTnH8TCxEkkEV@google.com \
    --to=smostafa@google.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jiangkunkun@huawei.com \
    --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=tangnianyao@huawei.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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).