[for 26.04_linux-nvidia-bos]: Backport the arm-smmu-v3 kdump adoption series by jamieNguyenNVIDIA · Pull Request #454 · NVIDIA/NV-Kernels

jamieNguyenNVIDIA · 2026-06-11T19:21:07Z

What This Fixes

This backports the arm-smmu-v3 kdump adoption series to avoid disrupting
in-flight DMA when the crash kernel boots.

Without this series, the crash kernel can reset/reprogram the SMMU while DMA
from the panicked kernel is still active. On the affected system this can show
up in BMC Redfish CPER logs as PCIe poisoned TLP and completion-timeout events
during kdump capture.

The fix lets the crash kernel detect that it is booting under kdump, adopt the
previous stream table, retain CR0_SMMUEN where needed, and defer attachment
for devices whose live DMA mappings must not be disturbed during crash dump
collection.

Backported Patches

Backported from:

https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t

This PR includes:

iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
iommu/arm-smmu-v3: Do not enable EVTQ/PRIQ interrupts in kdump kernel
iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup in kdump kernel
iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset
iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption
iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe()

The backport required only context-level adjustments for the target tree.

Testing

Repro flow:

Test script used: nvbug5963602_repro.sh

Configure kdump.
Generate read DMA traffic from NVMe devices.
Trigger SysRq crash while DMA is active.
Inspect BMC Redfish EventLog for PCIe CPER records.

The issue is timing-sensitive and difficult to reproduce reliably without
widening the crash-kernel SMMU window. For validation, I used a test-only delay
patch in the SMMU kdump path. The delay patch is not part of this PR.

Baseline confirmation:

Kernel: 6.17.13-b5963602-delay
Result: reproduced.
BMC Redfish logged PCIe CPER warning events with:
- Poisoned_tlp_received=true
- Completion_timeout_status=true

Backport testing with the same repro approach plus the test-only delay:

for_26.04_linux-nvidia-bos / 7.0-bos + delay:
- kdump completed
- crash kernel exercised the SMMU kdump adoption path
- no poisoned TLP or completion-timeout CPER was observed

Launchpad Bug

https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-7.0/+bug/2156531

When transitioning to a kdump kernel, the primary kernel might have crashed while endpoint devices were actively bus-mastering DMA. Currently, the SMMU driver aggressively resets the hardware during probe by clearing CR0_SMMUEN and setting the Global Bypass Attribute (GBPA) to ABORT. In a kdump scenario, this aggressive reset is highly destructive: a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal PCIe AER or SErrors that may panic the kdump kernel b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs. To safely absorb in-flight DMAs, a kdump kernel will have to leave SMMUEN=1 intact and avoid modifying STRTAB_BASE, allowing HW to continue translating in-flight DMAs reusing the crashed kernel's page tables until the endpoint device drivers probe and quiesce their respective hardware. However, the ARM SMMUv3 architecture specification states that updating the SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored. This leaves a kdump kernel no choice but to adopt the stream table from the crashed kernel. Introduce ARM_SMMU_OPT_KDUMP_ADOPT and adopt functions memremapping all the stream tables extracted from STRTAB_BASE and STRTAB_BASE_CFG. Note that the adoption of the crashed kernel's stream table follows certain strict rules, since the old stream table might be compromised. Thus, apply some basic validations against the values read from the registers. If tests fail, it means the stream table cannot be trusted, so toss it entirely. To avoid OOM due to a potentially corrupted stream table, the memremap for l2 tables is done on the kdump kernel's demand. The new option will be set in a following change. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

Though the kdump kernel adopts the crashed kernel's stream table, the iommu core will still try to attach each probed device to a default domain, which overwrites the adopted STE and breaks in-flight DMA from that device. Implement an is_attach_deferred() callback to prevent this. For each device that has STE.V=1 and STE.Cfg!=Abort in the adopted table, defer the default domain attachment, until the device driver explicitly requests it. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) [jamien: Resolve context conflict around arm_smmu_remove_master() due to the different surrounding arm-smmu-v3 code in this tree.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

In kdump cases, the crashed kernel's CDs and page tables can be corrupted, which could trigger event spamming. Also, we cannot serve page requests. Skip the IRQ setup for EVTQ/PRIQ in arm_smmu_setup_irqs(). Skip their IRQ handler registration in unique-IRQ and combined-IRQ cases. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

In kdump cases, the crashed kernel's CDs and page tables can be corrupted, which could trigger event spamming. Also, we cannot serve page requests. Skip the EVTQ/PRIQ setup entirely rather than enabling then disabling them. Also add some inline comments explaining that. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Suggested-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

When ARM_SMMU_OPT_KDUMP_ADOPT is detected, do not disable SMMUEN and skip the CR1/CR2/STRTAB_BASE update sequence in arm_smmu_device_reset(). Those register writes are all CONSTRAINED UNPREDICTABLE while CR0_SMMUEN==1, so leaving them intact lets in-flight DMAs continue to be translated by the adopted stream table. Initialize 'enables' to 0 so it can carry CR0_SMMUEN in kdump case. Then, preserve that when enabling the command queue. Clear latched gerror bits if necessary. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

RMR bypass STEs are installed during SMMUv3 probe for StreamIDs listed by IORT RMR nodes. A normal boot switches the driver to a fresh stream table whose initial STEs abort, so those RMR SIDs need bypass entries before it becomes live. This preserves firmware/guest-owned traffic, including vSMMU guest MSI cases built around RMR-described SIDs. ARM_SMMU_OPT_KDUMP_ADOPT is the opposite case: the driver keeps SMMUEN set and adopts the crashed kernel's stream table, so RMR SIDs already have the only translation state known to be safe for active in-flight DMA. Replacing an adopted STE with bypass can turn translated DMA into physical DMA, then point it at the wrong memory. arm_smmu_make_bypass_ste() also rewrites the STE in place after clearing it first. While the table is live, a concurrent hardware STE fetch can observe V=0 or mixed old/new state. Leaving the adopted STE unmodified keeps the kdump kernel using the crashed kernel's translation. That gives the endpoint driver a chance to probe and quiesce the device. If the old STE was already abort or invalid, installing bypass would create new DMA permission; leaving it alone is a safer failure mode. Later domain setup still gets the RMR direct mappings through the reserved-region path. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: Codex:gpt-5.5 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

arm_smmu_device_hw_probe() runs before arm_smmu_init_structures(), so it's natural to decide whether the kdump kernel must adopt the crashed kernel's stream table. Given that memremap is used to adopt the old stream table, set this option only on a coherent SMMU. And make sure SMMU isn't in Service Failure Mode. Fixes: b63b343 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel") Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> (backported from https://lore.kernel.org/linux-iommu/cover.1779265413.git.nicolinc@nvidia.com/#t) [jamien: Resolve context conflict around arm_smmu_device_hw_probe() due to the existing MPAM probe helper in this tree.] Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

github-actions · 2026-06-11T19:31:14Z

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details

Checking 8 commits...

Cherry-pick digest:
E: 54e02f4c1a2b ("iommu/arm-smmu-v3: Add arm_smmu_kdump_ad"): diff MISMATCH with lore patch (add [Author: reason] annotation if intentional)
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 836cb4a0e939 │ [SAUCE] iommu/arm-smmu-v3: block kdump mpam updates              │ N/A        │ N/A     │ jamien                    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ cf5b431f7223 │ iommu/arm-smmu-v3: detect arm_smmu_opt_kdump_adopt in probe()    │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ acb98c7c411c │ iommu/arm-smmu-v3: skip rmr bypass for kdump adoption            │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a94e112ffe1d │ iommu/arm-smmu-v3: retain cr0_smmuen during kdump device reset   │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ ce9c8d8132cd │ iommu/arm-smmu-v3: skip evtq/priq setup in kdump kernel          │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 0793434ff69e │ iommu/arm-smmu-v3: do not enable evtq/priq interrupts in kdump k │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 50f831274d3d │ iommu/arm-smmu-v3: implement is_attach_deferred() for kdump      │ match      │ found   │ ok, backporter: jamien    │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 54e02f4c1a2b │ iommu/arm-smmu-v3: add arm_smmu_kdump_adopt_strtab() for kdump   │ MISMATCH   │ found   │ ok, backporter: jamien    │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

nirmoy · 2026-06-11T20:09:58Z

BaseOS Kernel Review

Summary

No issues found across the reviewed commits.

Findings: no problems found

Latest watcher review: open review

Kernel deb build: successful (download debs, 4 files)

Head: 836cb4a0e939

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

clsotog · 2026-06-11T22:08:35Z

These are the findings with Codex:

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4758 re-enables CR0_ATSCHK in the kdump-adopt path. Earlier the code preserves only the crashed kernel’s CR0_SMMUEN|CR0_ATSCHK state, but the common ATS block later forces ATSCHK on whenever the feature exists. That
changes ATS policy while SMMUEN is intentionally kept live. Gate this block out for ARM_SMMU_OPT_KDUMP_ADOPT, or only preserve the old bit.
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4679 can silently continue adoption if GERROR_SFM_ERR appears after arm_smmu_device_hw_probe_kdump() checked it. The reset path acks all active GERROR bits and proceeds. Since the probe helper treats SFM as “must
reset,” re-check active & GERROR_SFM_ERR here before clearing and continuing.
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3922 has a backport-specific MPAM interaction: arm_smmu_group_set_mpam() edits STE words and issues CFGI_STE even for a device whose attach is still deferred. iommu_group_set_qos_params() can call this without checking
attach_deferred. That undermines the PR’s “leave adopted STEs alone until the driver quiesces the endpoint” rule.

jamieNguyenNVIDIA · 2026-06-12T00:39:37Z

These are the findings with Codex:

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4758 re-enables CR0_ATSCHK in the kdump-adopt path. Earlier the code preserves only the crashed kernel’s CR0_SMMUEN|CR0_ATSCHK state, but the common ATS block later forces ATSCHK on whenever the feature exists. That
changes ATS policy while SMMUEN is intentionally kept live. Gate this block out for ARM_SMMU_OPT_KDUMP_ADOPT, or only preserve the old bit.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4679 can silently continue adoption if GERROR_SFM_ERR appears after arm_smmu_device_hw_probe_kdump() checked it. The reset path acks all active GERROR bits and proceeds. Since the probe helper treats SFM as “must
reset,” re-check active & GERROR_SFM_ERR here before clearing and continuing.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3922 has a backport-specific MPAM interaction: arm_smmu_group_set_mpam() edits STE words and issues CFGI_STE even for a device whose attach is still deferred. iommu_group_set_qos_params() can call this without checking
attach_deferred. That undermines the PR’s “leave adopted STEs alone until the driver quiesces the endpoint” rule.

I checked with Nicolin on 1 and 2 since those were inherited from upstream:

Neither seems necessary to me.
1.  ATSCHK is aligned with the crashed kernel. The only case we really care: 
    if crashed kernel has ATSCHK set, kdump kernel must set it too to keep ATS alive.
2.  SFM would not be cleared by acking the gerror register. So, it will stay and
    the IRQ will raise to flag it.

looks to be an with the backport -- I'll evaluate that one.

clsotog · 2026-06-12T02:44:50Z

These are the findings with Codex:

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4758 re-enables CR0_ATSCHK in the kdump-adopt path. Earlier the code preserves only the crashed kernel’s CR0_SMMUEN|CR0_ATSCHK state, but the common ATS block later forces ATSCHK on whenever the feature exists. That
changes ATS policy while SMMUEN is intentionally kept live. Gate this block out for ARM_SMMU_OPT_KDUMP_ADOPT, or only preserve the old bit.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4679 can silently continue adoption if GERROR_SFM_ERR appears after arm_smmu_device_hw_probe_kdump() checked it. The reset path acks all active GERROR bits and proceeds. Since the probe helper treats SFM as “must
reset,” re-check active & GERROR_SFM_ERR here before clearing and continuing.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3922 has a backport-specific MPAM interaction: arm_smmu_group_set_mpam() edits STE words and issues CFGI_STE even for a device whose attach is still deferred. iommu_group_set_qos_params() can call this without checking
attach_deferred. That undermines the PR’s “leave adopted STEs alone until the driver quiesces the endpoint” rule.

I checked with Nicolin on 1 and 2 since those were inherited from upstream:
Neither seems necessary to me.
1.  ATSCHK is aligned with the crashed kernel. The only case we really care: 
    if crashed kernel has ATSCHK set, kdump kernel must set it too to keep ATS alive.
2.  SFM would not be cleared by acking the gerror register. So, it will stay and
    the IRQ will raise to flag it.
looks to be an with the backport -- I'll evaluate that one.

thanks

The kdump adoption backport preserves live STEs until device attach has been re-established. MPAM QoS updates can rewrite STE PARTID/PMG fields before deferred attach is resolved. That can modify an adopted live STE while DMA may still be in flight. Reject MPAM QoS updates while kdump adoption is active and the device still has attach_deferred set. The IOMMU core clears attach_deferred after a successful real attach, so normal MPAM updates are unchanged after the device is attached. Non-kdump boots are unchanged. Signed-off-by: Jamie Nguyen <jamien@nvidia.com>

jamieNguyenNVIDIA · 2026-06-12T03:32:25Z

These are the findings with Codex:

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4758 re-enables CR0_ATSCHK in the kdump-adopt path. Earlier the code preserves only the crashed kernel’s CR0_SMMUEN|CR0_ATSCHK state, but the common ATS block later forces ATSCHK on whenever the feature exists. That
changes ATS policy while SMMUEN is intentionally kept live. Gate this block out for ARM_SMMU_OPT_KDUMP_ADOPT, or only preserve the old bit.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:4679 can silently continue adoption if GERROR_SFM_ERR appears after arm_smmu_device_hw_probe_kdump() checked it. The reset path acks all active GERROR bits and proceeds. Since the probe helper treats SFM as “must
reset,” re-check active & GERROR_SFM_ERR here before clearing and continuing.

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3922 has a backport-specific MPAM interaction: arm_smmu_group_set_mpam() edits STE words and issues CFGI_STE even for a device whose attach is still deferred. iommu_group_set_qos_params() can call this without checking
attach_deferred. That undermines the PR’s “leave adopted STEs alone until the driver quiesces the endpoint” rule.

I checked with Nicolin on 1 and 2 since those were inherited from upstream:
Neither seems necessary to me.
1.  ATSCHK is aligned with the crashed kernel. The only case we really care: 
    if crashed kernel has ATSCHK set, kdump kernel must set it too to keep ATS alive.
2.  SFM would not be cleared by acking the gerror register. So, it will stay and
    the IRQ will raise to flag it.
looks to be an with the backport -- I'll evaluate that one.
thanks

I've added a SAUCE commit that ought to address #3. It's SAUCE because this is an MPAM path that's only present in the -bos branch.

(NVIDIA/NV-Kernels#454).

kernel (NVIDIA/NV-Kernels#454).

(NVIDIA/NV-Kernels#454).

clsotog · 2026-06-12T16:06:16Z

I've added a SAUCE commit that ought to address #3. It's SAUCE because this is an MPAM path that's only present in the -bos branch.

I got this finding from Codex:
nv-kernels-pr454-review/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3921 relies on dev->iommu->attach_deferred to decide whether MPAM must avoid rewriting an adopted STE. That bit is not only cleared after successful attach: the core clears it before attempting a non-default domain attach at nv-kernels-pr454-review/drivers/iommu/iommu.c:2432, then returns
on attach failure without restoring it. After such a failed attach, the adopted STE can still be live, but MPAM updates are no longer blocked and can rewrite PARTID/PMG on that live entry. This needs a state bit that is cleared only after successful STE replacement, or the core needs to preserve/restore attach_deferred on failed attaches.

jamieNguyenNVIDIA · 2026-06-12T16:30:23Z

I've added a SAUCE commit that ought to address #3. It's SAUCE because this is an MPAM path that's only present in the -bos branch.

I got this finding from Codex: nv-kernels-pr454-review/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3921 relies on dev->iommu->attach_deferred to decide whether MPAM must avoid rewriting an adopted STE. That bit is not only cleared after successful attach: the core clears it before attempting a non-default domain attach at nv-kernels-pr454-review/drivers/iommu/iommu.c:2432, then returns on attach failure without restoring it. After such a failed attach, the adopted STE can still be live, but MPAM updates are no longer blocked and can rewrite PARTID/PMG on that live entry. This needs a state bit that is cleared only after successful STE replacement, or the core needs to preserve/restore attach_deferred on failed attaches.

I think this is accurate, but I'd prefer to keep the SAUCE patch as-is rather than adding more state tracking for this corner case. I think the patch still blocks the normal kdump-adopt window that we really care about in this PR.

clsotog · 2026-06-12T18:15:40Z

I've added a SAUCE commit that ought to address #3. It's SAUCE because this is an MPAM path that's only present in the -bos branch.

I got this finding from Codex: nv-kernels-pr454-review/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3921 relies on dev->iommu->attach_deferred to decide whether MPAM must avoid rewriting an adopted STE. That bit is not only cleared after successful attach: the core clears it before attempting a non-default domain attach at nv-kernels-pr454-review/drivers/iommu/iommu.c:2432, then returns on attach failure without restoring it. After such a failed attach, the adopted STE can still be live, but MPAM updates are no longer blocked and can rewrite PARTID/PMG on that live entry. This needs a state bit that is cleared only after successful STE replacement, or the core needs to preserve/restore attach_deferred on failed attaches.

I think this is accurate, but I'd prefer to keep the SAUCE patch as-is rather than adding more state tracking for this corner case. I think the patch still blocks the normal kdump-adopt window that we really care about in this PR.

Thats fine.

Acked-by: Carol L Soto <csoto@nvidia.com>

(NVIDIA/NV-Kernels#454). suse-commit: 0cec5ef4808ae56bb0548b507a923e85452049d8

(NVIDIA/NV-Kernels#454). suse-commit: d5f8440896e7fb578ad13c846859b0f00cc5ef84

(NVIDIA/NV-Kernels#454). suse-commit: 2aa6c7386c0f8c736dc7a633cf98ca949611ea34

(NVIDIA/NV-Kernels#454). suse-commit: 79886f1d3ed0bd775cd54fa8c3f19452399b4f8c

(NVIDIA/NV-Kernels#454). suse-commit: 3b2eb1837227f8d4af1bc193031b167a6b3274ea

kernel (NVIDIA/NV-Kernels#454). suse-commit: a43296af23a1091e24b6aca6740b90972bf53964

(NVIDIA/NV-Kernels#454). suse-commit: be853ac5a11811353fcf6bc8e9277323f9b111cb

nicolinc added 7 commits June 11, 2026 11:28

jamieNguyenNVIDIA requested review from clsotog, ltrager, nirmoy, nvmochs and sforshee June 11, 2026 19:21

nirmoy added the help wanted Extra attention is needed label Jun 11, 2026

jamieNguyenNVIDIA force-pushed the jamien/backport-iommu-nesting-2604-bos branch from 9391e78 to 836cb4a Compare June 12, 2026 03:30

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump

0cec5ef

(NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset

d5f8440

(NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump

2aa6c73

(NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup in kdump kernel

79886f1

(NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption

3b2eb18

(NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Do not enable EVTQ/PRIQ interrupts in kdump

a43296a

kernel (NVIDIA/NV-Kernels#454).

suse-kernel pushed a commit to SUSE/kernel-source that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe()

be853ac

(NVIDIA/NV-Kernels#454).

clsotog approved these changes Jun 12, 2026

View reviewed changes

nirmoy added has_1_ack and removed help wanted Extra attention is needed labels Jun 12, 2026

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump

e625665

(NVIDIA/NV-Kernels#454). suse-commit: 0cec5ef4808ae56bb0548b507a923e85452049d8

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset

9310984

(NVIDIA/NV-Kernels#454). suse-commit: d5f8440896e7fb578ad13c846859b0f00cc5ef84

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump

829d979

(NVIDIA/NV-Kernels#454). suse-commit: 2aa6c7386c0f8c736dc7a633cf98ca949611ea34

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup in kdump kernel

603f05a

(NVIDIA/NV-Kernels#454). suse-commit: 79886f1d3ed0bd775cd54fa8c3f19452399b4f8c

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption

f535c22

(NVIDIA/NV-Kernels#454). suse-commit: 3b2eb1837227f8d4af1bc193031b167a6b3274ea

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Do not enable EVTQ/PRIQ interrupts in kdump

9a15b88

kernel (NVIDIA/NV-Kernels#454). suse-commit: a43296af23a1091e24b6aca6740b90972bf53964

suse-kernel pushed a commit to SUSE/kernel that referenced this pull request Jun 12, 2026

iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe()

e372ae2

(NVIDIA/NV-Kernels#454). suse-commit: be853ac5a11811353fcf6bc8e9277323f9b111cb

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[for 26.04_linux-nvidia-bos]: Backport the arm-smmu-v3 kdump adoption series#454

[for 26.04_linux-nvidia-bos]: Backport the arm-smmu-v3 kdump adoption series#454
jamieNguyenNVIDIA wants to merge 8 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
jamieNguyenNVIDIA:jamien/backport-iommu-nesting-2604-bos

jamieNguyenNVIDIA commented Jun 11, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 11, 2026 •

edited

Loading

Uh oh!

nirmoy commented Jun 11, 2026 •

edited

Loading

Uh oh!

clsotog commented Jun 11, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026 •

edited

Loading

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

jamieNguyenNVIDIA commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What This Fixes

Backported Patches

Testing

Launchpad Bug

Uh oh!

github-actions Bot commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Validation Report

Patchscan ✅ No Missing Fixes

PR Lint ❌ Errors found

Uh oh!

nirmoy commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

BaseOS Kernel Review

Summary

Uh oh!

clsotog commented Jun 11, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

jamieNguyenNVIDIA commented Jun 12, 2026

Uh oh!

clsotog commented Jun 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jamieNguyenNVIDIA commented Jun 11, 2026 •

edited

Loading

github-actions Bot commented Jun 11, 2026 •

edited

Loading

nirmoy commented Jun 11, 2026 •

edited

Loading

jamieNguyenNVIDIA commented Jun 12, 2026 •

edited

Loading