mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arun Iyengar via B4 Relay <devnull+aiyengar1990.gmail.com@kernel.org>
To: "Joerg Roedel (AMD)" <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	 Robin Murphy <robin.murphy@arm.com>,
	Chen-Yu Tsai <wens@kernel.org>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	 Samuel Holland <samuel@sholland.org>,
	Maxime Ripard <mripard@kernel.org>
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	 linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] iommu/sun50i: Don't report TLB prefetches of unmapped pages as faults
Date: Tue, 10 Nov 2026 06:05:17 +0000	[thread overview]
Message-ID: <20261110-sun50i-iommu-prefetch-v1-1-43428e792ef6@gmail.com> (raw)
In-Reply-To: <20261110-sun50i-iommu-prefetch-v1-0-43428e792ef6@gmail.com>

From: Arun Iyengar <aiyengar1990@gmail.com>

With a display scanning out, the driver reports

  sun50i-iommu 30f0000.iommu: Page fault for 0x00000000fff00000 (master -1, dir rd)

on an H616 once when fbcon takes over the framebuffer (the first
scanout frame), and again, vsync-spaced, after TLB flushes while a video
decoder frees its buffers (every unmap flushes the whole TLB and PTW
cache in this driver). No device accesses that address: with the IOVA
allocator handing out addresses from the top down and size-aligned, the
3 MiB fbcon framebuffer of a 1024x768 mode is the first allocation and
lands at 0xffc00000-0xffefffff, and the top 1 MiB of the IOVA space
above it is never mapped. 0xfff00000 is the page after the end of the
framebuffer.

The walk that fails is the TLB prefetcher's, for the page after the one
the master is reading. The H616 user manual (3.12.6.50, 3.12.6.51) gives
the L1/L2 page table interrupt registers a bit 31 next to the per-master
bits for walks that no master started, and Allwinner's sunxi-iommu
driver treats a page table interrupt with bit 31 set as a prefetch of an
unmapped page ("It's OK to prefetch an invalid pagetable") and does not
report it. This driver masks the register to the master bits, gets no
bit, and reports ilog2(0) = -1 as the master.

Return early for a page table interrupt with the prefetch bit set and no
master bit: no master read anything and nothing is stalled, so there is
nothing to report, reset or zap. Print such walks with dev_dbg so they
can still be counted.

Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
 drivers/iommu/sun50i-iommu.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index be3f1ce696ba..1b7a7f0d9b62 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -73,6 +73,15 @@
 #define IOMMU_INT_ERR_DATA_REG(i)	(0x150 + (i) * 4)
 #define IOMMU_L1PG_INT_REG		0x0180
 #define IOMMU_L2PG_INT_REG		0x0184
+/*
+ * Besides one bit per master, the L1/L2 page table interrupt registers
+ * have a bit for a page table walk that no master started: the TLB
+ * prefetcher's walk for the page after the one being accessed (H616 user
+ * manual 3.12.6.50 and 3.12.6.51, bit 31, "debug mode"; the vendor's
+ * sunxi-iommu treats a page table fault with this bit as a prefetch of an
+ * unmapped page and does not report it).
+ */
+#define IOMMU_PG_INT_PREFETCH			BIT(31)
 
 #define IOMMU_INT_INVALID_L2PG			BIT(17)
 #define IOMMU_INT_INVALID_L1PG			BIT(16)
@@ -891,6 +900,20 @@ static phys_addr_t sun50i_iommu_handle_pt_irq(struct sun50i_iommu *iommu,
 
 	iova = iommu_read(iommu, addr_reg);
 	blame = iommu_read(iommu, blame_reg);
+
+	/*
+	 * A walk the TLB prefetcher started for the page after the one a
+	 * master is reading fails whenever that next page is not mapped,
+	 * e.g. for the display engine scanning out a framebuffer that ends
+	 * at an unmapped IOVA. No master accessed the page and nothing is
+	 * stalled or cached, so there is nothing to report, reset or zap.
+	 */
+	if ((blame & IOMMU_PG_INT_PREFETCH) && !(blame & IOMMU_INT_MASTER_MASK)) {
+		dev_dbg_ratelimited(iommu->dev, "page table prefetch of unmapped %pad\n",
+				    &iova);
+		return iova;
+	}
+
 	master = ilog2(blame & IOMMU_INT_MASTER_MASK);
 
 	/*

-- 
2.55.0



  reply	other threads:[~2026-11-10  6:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  6:05 [PATCH 0/2] iommu/sun50i: Don't report TLB prefetch walks as page faults Arun Iyengar via B4 Relay
2026-11-10  6:05 ` Arun Iyengar via B4 Relay [this message]
2026-11-10  6:05 ` [PATCH 2/2] iommu/sun50i: Print the page table level and status of a fault Arun Iyengar via B4 Relay
2026-11-10 16:04 ` [PATCH 0/2] iommu/sun50i: Don't report TLB prefetch walks as page faults Jernej Škrabec

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=20261110-sun50i-iommu-prefetch-v1-1-43428e792ef6@gmail.com \
    --to=devnull+aiyengar1990.gmail.com@kernel.org \
    --cc=aiyengar1990@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=jernej.skrabec@gmail.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mripard@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=samuel@sholland.org \
    --cc=wens@kernel.org \
    --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

all inboxes | Powered by JetHome®