From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>, <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>, <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Johan Hovold <johan@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Pranjal Shrivastava <praan@google.com>,
"Mostafa Saleh" <smostafa@google.com>,
<linux-kernel@vger.kernel.org>, <iommu@lists.linux.dev>,
<driver-core@lists.linux.dev>, Sonang Patel <sonangp@nvidia.com>,
Ankit Agrawal <ankita@nvidia.com>,
<shameerali.kolothum.thodi@huawei.com>
Subject: [PATCH v2 0/7] iommu/arm-smmu-v3: Support guest-level Realm VSMMU (Part-1)
Date: Mon, 2 Nov 2026 19:49:43 -0800 [thread overview]
Message-ID: <cover.1793676742.git.nicolinc@nvidia.com> (raw)
This series prepares Realm guest IOMMU and DMA subsystems for devices that
are present but not yet inside the Realm trust boundary.
Inside a confidential guest, we expect that all the iommus are going to be
T=1 aware; there seems to be no interest in supporting IOMMUs that handle
T=0 only. This means they only work on devices that have been put into the
run state and issue T=1 transactions.
Today an iommu driver assumes it translates for every device behind it: it
probes the device, takes a translating default domain, and puts the DMA API
on its page tables. That assumption is wrong for T=0 devices, whose DMA the
hypervisor translates instead, so the mappings made by the guest are never
consulted and the device silently stops working.
To solve this problem, make TDISP T=0 the default for devices associated
with a confidential IOMMU. The tdisp_t1 flag records the future T=1 state.
While T=0, the device remains outside the Realm trust boundary. Its DMA is
translated by the host or hypervisor:
[device: T=0] ===> [hypervisor] ===> [memory]
|
+-- (guest association) --> [confidential IOMMU: blocking DMA]
Legend: ===> DMA path; --> guest topology and control
After reaching T=1, the device is inside the Realm trust boundary. Its DMA
may use the guest VSMMU after RMM binds the device to its virtual stream:
[device] ===> [VSMMU: S1] ===> [RMM/PSMMU: S2 + DPT] ===> [memory]
As part 1 of Realm VSMMU support, implement enough core infrastructure to
manage a confidential vIOMMU:
- Detect and mark it as confidential in the core iommu structures
- Support devices in T=0 mode by keeping the DMA API in direct mode. The
iommu is up and running, but parks such a device in its blocking domain
and translates for nothing, as the core takes over what the device still
needs, which today is ATS
- Keep it parked: refuse a translating domain by every route in, whether
through the default domain, sysfs, group attach or replace, or PASID
Part 1 only adds the helpers required for T=0 setup and teardown. It does
not add iommu_tdisp_enter_t1() until part 2 has a transition to perform.
Then implement SMMUv3 support:
- Let a CPU-integrated IOMMU declare that its DMA can reach private
memory, so coherent allocations and streaming mappings avoid the SWIOTLB
shared pool
- Identify a T=1 VSMMU using trusted RSI because firmware does not
distinguish it from a normal T=0 SMMU
- Validate the firmware MMIO range against RSI before activating the VSMMU
and allocating its queues and tables from private memory
The series is on github:
https://github.com/nicolinc/iommufd/commits/smmuv3_realm_guest_p1-v2
Changelog
v2:
* Rebase on v7.4-rc1
* Drop Assisted-by tags
* Drop Aneesh's firmware patch that was merged
* Skip Tegra CMDQV implementation in the realm world
* Use arm_smccc_1_2_smc() to zero inputs as RMM spec demands
* Add missing iommu_using_t0_stream() check in iommu_dma_prepare_msi()
v1:
https://lore.kernel.org/all/cover.1789010941.git.nicolinc@nvidia.com/
Future work
===========
Part 2 will add the T=1 transition after validation through:
- TSM, whose guest-side interface remains under discussion
- RMM, using the Arm-specific RSI VDEV command
For a multi-device IOMMU group, the first device accepted into T=1 claims
the group. Part 2 will reject T=1 for every other member.
The current RSI binding validation returns one VSID, so part 2 must reject
a firmware specification containing multiple SIDs upon the T=1 transition.
Nicolin Chen (7):
firmware: arm_rmm: Add VSMMU commands and fields
dma-mapping: Let a device declare that it reaches private memory
dma-mapping: Keep DMA memory private for capable devices
iommu: Let a driver mark an IOMMU as confidential
iommu: Introduce TDISP T=0 state for confidential IOMMUs
iommu: Park TDISP T=0 devices in the blocking domain
iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands
drivers/iommu/Makefile | 3 +
drivers/iommu/iommu-priv.h | 19 +++++
include/linux/arm-rsi-cmds.h | 29 +++++++
include/linux/arm-smccc-rsi.h | 20 +++++
include/linux/device.h | 4 +
include/linux/dma-direct.h | 7 +-
include/linux/dma-mapping.h | 4 +
include/linux/iommu.h | 14 ++++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 64 ++++++++++++++-
drivers/iommu/iommu-cc.c | 57 +++++++++++++
drivers/iommu/iommu.c | 91 +++++++++++++++++++--
kernel/dma/direct.c | 16 ++--
kernel/dma/mapping.c | 23 +++++-
kernel/dma/swiotlb.c | 2 +-
14 files changed, 335 insertions(+), 18 deletions(-)
create mode 100644 drivers/iommu/iommu-cc.c
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
--
2.43.0
next reply other threads:[~2026-11-03 3:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 3:49 Nicolin Chen [this message]
2026-11-03 3:49 ` [PATCH v2 1/7] firmware: arm_rmm: Add VSMMU commands and fields Nicolin Chen
2026-11-03 3:49 ` [PATCH v2 2/7] dma-mapping: Let a device declare that it reaches private memory Nicolin Chen
2026-11-03 10:11 ` Marek Szyprowski
2026-11-03 3:49 ` [PATCH v2 3/7] dma-mapping: Keep DMA memory private for capable devices Nicolin Chen
2026-11-03 10:10 ` Marek Szyprowski
2026-11-03 3:49 ` [PATCH v2 4/7] iommu: Let a driver mark an IOMMU as confidential Nicolin Chen
2026-11-03 3:49 ` [PATCH v2 5/7] iommu: Introduce TDISP T=0 state for confidential IOMMUs Nicolin Chen
2026-11-03 3:49 ` [PATCH v2 6/7] iommu: Park TDISP T=0 devices in the blocking domain Nicolin Chen
2026-11-03 3:49 ` [PATCH v2 7/7] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands Nicolin Chen
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=cover.1793676742.git.nicolinc@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=ankita@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=johan@kernel.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=praan@google.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=smostafa@google.com \
--cc=sonangp@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.