Linux IOMMU Development
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Ashish Kalra <ashish.kalra@amd.com>,
	Vasant Hegde <vasant.hegde@amd.com>,
	Sairaj Kodilkar <sarunkod@amd.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Sasha Levin <sashal@kernel.org>,
	joro@8bytes.org, iommu@lists.linux.dev
Subject: [PATCH AUTOSEL 6.17-5.10] iommu/amd: Skip enabling command/event buffers for kdump
Date: Sat, 25 Oct 2025 11:57:27 -0400	[thread overview]
Message-ID: <20251025160905.3857885-216-sashal@kernel.org> (raw)
In-Reply-To: <20251025160905.3857885-1-sashal@kernel.org>

From: Ashish Kalra <ashish.kalra@amd.com>

[ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ]

After a panic if SNP is enabled in the previous kernel then the kdump
kernel boots with IOMMU SNP enforcement still enabled.

IOMMU command buffers and event buffer registers remain locked and
exclusive to the previous kernel. Attempts to enable command and event
buffers in the kdump kernel will fail, as hardware ignores writes to
the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1.

Skip enabling command buffers and event buffers for kdump boot as they
are already enabled in the previous kernel.

Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- What it fixes
  - Kdump boot after a panic with AMD SNP: IOMMU command/event buffer
    base registers remain locked to the previous kernel, so programming
    them in the crash kernel is ignored (per AMD IOMMU spec 2.12.2.1).
    This prevents enabling command/event buffers and breaks IOMMU
    operation in the crash kernel.

- Key changes
  - Skips writing command buffer base in kdump:
    `drivers/iommu/amd/init.c:824-833`. The write to
    `MMIO_CMD_BUF_OFFSET` is now gated by `if (!is_kdump_kernel())`,
    while still resetting and enabling the ring via
    `amd_iommu_reset_cmd_buffer()` (`drivers/iommu/amd/init.c:835`).
  - Skips writing event buffer base in kdump:
    `drivers/iommu/amd/init.c:884-892`. Similarly, the write to
    `MMIO_EVT_BUF_OFFSET` is skipped in kdump; head/tail registers are
    cleared and logging enabled (`drivers/iommu/amd/init.c:894-899`).

- Why it’s correct and low risk
  - The driver already reuses/remaps the previous kernel’s buffers in
    kdump:
    - Event buffer remap from existing MMIO base:
      `drivers/iommu/amd/init.c:987-996`.
    - Command buffer remap from existing MMIO base:
      `drivers/iommu/amd/init.c:998-1006`.
    - Kdump buffer provisioning path:
      `drivers/iommu/amd/init.c:1039-1050`.
  - With those remaps, `iommu->cmd_buf` and `iommu->evt_buf` point to
    the same memory the hardware is locked to, so skipping the base
    register writes is necessary and safe; the driver still resets
    head/tail and enables the features so operation resumes as expected.
  - This matches existing kdump policy to avoid touching locked
    registers, e.g. device table programming is skipped in kdump:
    `drivers/iommu/amd/init.c:409`.
  - Scope is small, localized to AMD IOMMU init paths, and guarded by
    `is_kdump_kernel()`, so normal boots are unaffected.

- User impact and stability criteria
  - Fixes a real reliability bug in crash dump scenarios on SNP-enabled
    systems; improves kdump robustness without adding features or
    architectural changes.
  - Changes are minimal and well-contained; only affect the kdump path.
  - No ABI or interface changes; limited to initialization register
    programming avoidance in kdump.

- Dependencies/considerations for backport
  - Ensure the kdump remap paths for command/event/CWB buffers are
    present so that `iommu->cmd_buf` and `iommu->evt_buf` reference the
    pre-existing hardware buffer addresses (see
    `drivers/iommu/amd/init.c:987-996`, `998-1006`, `1039-1050`). This
    commit relies on those existing mechanisms; backport alongside those
    if they’re not already in the target stable tree.

Given the above, this is a good stable backport candidate: important
bugfix, minimal risk, and confined to the kdump path for AMD IOMMU.

 drivers/iommu/amd/init.c | 28 +++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 309951e57f301..d0cd40ee0dec6 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -815,11 +815,16 @@ static void iommu_enable_command_buffer(struct amd_iommu *iommu)
 
 	BUG_ON(iommu->cmd_buf == NULL);
 
-	entry = iommu_virt_to_phys(iommu->cmd_buf);
-	entry |= MMIO_CMD_SIZE_512;
-
-	memcpy_toio(iommu->mmio_base + MMIO_CMD_BUF_OFFSET,
-		    &entry, sizeof(entry));
+	if (!is_kdump_kernel()) {
+		/*
+		 * Command buffer is re-used for kdump kernel and setting
+		 * of MMIO register is not required.
+		 */
+		entry = iommu_virt_to_phys(iommu->cmd_buf);
+		entry |= MMIO_CMD_SIZE_512;
+		memcpy_toio(iommu->mmio_base + MMIO_CMD_BUF_OFFSET,
+			    &entry, sizeof(entry));
+	}
 
 	amd_iommu_reset_cmd_buffer(iommu);
 }
@@ -870,10 +875,15 @@ static void iommu_enable_event_buffer(struct amd_iommu *iommu)
 
 	BUG_ON(iommu->evt_buf == NULL);
 
-	entry = iommu_virt_to_phys(iommu->evt_buf) | EVT_LEN_MASK;
-
-	memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
-		    &entry, sizeof(entry));
+	if (!is_kdump_kernel()) {
+		/*
+		 * Event buffer is re-used for kdump kernel and setting
+		 * of MMIO register is not required.
+		 */
+		entry = iommu_virt_to_phys(iommu->evt_buf) | EVT_LEN_MASK;
+		memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
+			    &entry, sizeof(entry));
+	}
 
 	/* set head and tail to zero manually */
 	writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
-- 
2.51.0


  parent reply	other threads:[~2025-10-25 16:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20251025160905.3857885-1-sashal@kernel.org>
2025-10-25 15:54 ` [PATCH AUTOSEL 6.17] iommu/vt-d: Remove LPIG from page group response descriptor Sasha Levin
2025-10-25 15:57 ` Sasha Levin [this message]
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17] iommu/amd: Reuse device table for kdump Sasha Levin
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17-5.15] iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot() Sasha Levin
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17-6.6] iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs Sasha Levin
2025-10-25 15:59 ` [PATCH AUTOSEL 6.17] iommu/amd: Add support to remap/unmap IOMMU buffers for kdump Sasha Levin

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=20251025160905.3857885-216-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=ashish.kalra@amd.com \
    --cc=iommu@lists.linux.dev \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=patches@lists.linux.dev \
    --cc=sarunkod@amd.com \
    --cc=stable@vger.kernel.org \
    --cc=vasant.hegde@amd.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