From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>, <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
<aneesh.kumar@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Gavin Shan <gshan@redhat.com>, Vikram Sethi <vsethi@nvidia.com>,
"Anshuman Khandual" <anshuman.khandual@arm.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Mostafa Saleh <smostafa@google.com>, <rppt@kernel.org>,
Thomas Huth <thuth@redhat.com>, Marc Zyngier <maz@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>, <kas@kernel.org>,
Kohei Enju <enju.kohei@fujitsu.com>,
Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>,
Ard Biesheuvel <ardb@kernel.org>,
James Morse <james.morse@arm.com>,
Steven Price <steven.price@arm.com>,
Sang-Heon Jeon <ekffu200098@gmail.com>,
Omar Sandoval <osandov@fb.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jinjie Ruan <ruanjinjie@huawei.com>,
Sam Edwards <cfsworks@gmail.com>,
Douglas Anderson <dianders@chromium.org>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
Chen-Yu Tsai <wenst@chromium.org>,
Huacai Chen <chenhuacai@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Pranjal Shrivastava <praan@google.com>,
Ashish Mhetre <amhetre@nvidia.com>,
Shameer Kolothum <skolothumtho@nvidia.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <iommu@lists.linux.dev>,
<driver-core@lists.linux.dev>, Sonang Patel <sonangp@nvidia.com>,
Ankit Agrawal <ankita@nvidia.com>
Subject: [PATCH v1 0/8] iommu/arm-smmu-v3: Support guest-level Realm VSMMU (Part-1)
Date: Wed, 9 Sep 2026 20:32:43 -0700 [thread overview]
Message-ID: <cover.1789010941.git.nicolinc@nvidia.com> (raw)
[ PATCH-1 in this series is a provisional cherry-pick from Aneesh's series
that moves the RSI layer out of arch/arm64, per Will's request. I added
it here to base the entire series on a public commit ID so that Sashiko
can start its job. So, I kept it as-is mostly, with Jason's review tag. ]
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-v1
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.
Aneesh Kumar K.V (Arm) (1):
firmware: arm_rmm: Move RSI support out of arch/arm64
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
arch/arm64/Kconfig | 1 +
drivers/firmware/Kconfig | 1 +
drivers/firmware/arm_rmm/Kconfig | 18 ++++
drivers/virt/coco/arm-cca-guest/Kconfig | 2 +-
arch/arm64/kernel/Makefile | 2 +-
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_rmm/Makefile | 2 +
drivers/iommu/Makefile | 3 +
arch/arm64/include/asm/io.h | 2 +-
arch/arm64/include/asm/mem_encrypt.h | 2 +-
arch/arm64/include/asm/pgtable-prot.h | 2 +-
arch/arm64/include/asm/rsi.h | 70 -------------
drivers/iommu/iommu-priv.h | 19 ++++
.../linux/arm-rsi-cmds.h | 99 ++++++++++++++++++-
.../linux/arm-smccc-rsi.h | 26 ++++-
include/linux/device.h | 4 +
include/linux/dma-direct.h | 7 +-
include/linux/dma-mapping.h | 4 +
include/linux/iommu.h | 14 +++
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/mm/init.c | 3 +-
.../kernel => drivers/firmware/arm_rmm}/rsi.c | 2 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 55 +++++++++++
drivers/iommu/iommu-cc.c | 57 +++++++++++
drivers/iommu/iommu.c | 86 +++++++++++++++-
.../virt/coco/arm-cca-guest/arm-cca-guest.c | 5 +-
kernel/dma/direct.c | 16 +--
kernel/dma/mapping.c | 23 ++++-
kernel/dma/swiotlb.c | 2 +-
29 files changed, 427 insertions(+), 103 deletions(-)
create mode 100644 drivers/firmware/arm_rmm/Kconfig
create mode 100644 drivers/firmware/arm_rmm/Makefile
delete mode 100644 arch/arm64/include/asm/rsi.h
rename arch/arm64/include/asm/rsi_cmds.h => include/linux/arm-rsi-cmds.h (64%)
rename arch/arm64/include/asm/rsi_smc.h => include/linux/arm-smccc-rsi.h (90%)
rename {arch/arm64/kernel => drivers/firmware/arm_rmm}/rsi.c (99%)
create mode 100644 drivers/iommu/iommu-cc.c
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
--
2.43.0
next reply other threads:[~2026-09-10 3:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 3:32 Nicolin Chen [this message]
2026-09-10 3:32 ` [PATCH v1 1/8] firmware: arm_rmm: Move RSI support out of arch/arm64 Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 2/8] firmware: arm_rmm: Add VSMMU commands and fields Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 3/8] dma-mapping: Let a device declare that it reaches private memory Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 4/8] dma-mapping: Keep DMA memory private for capable devices Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 5/8] iommu: Let a driver mark an IOMMU as confidential Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 6/8] iommu: Introduce TDISP T=0 state for confidential IOMMUs Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 7/8] iommu: Park TDISP T=0 devices in the blocking domain Nicolin Chen
2026-09-10 3:32 ` [PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands Nicolin Chen
2026-09-10 4:23 ` 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.1789010941.git.nicolinc@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=amhetre@nvidia.com \
--cc=aneesh.kumar@kernel.org \
--cc=ankita@nvidia.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cfsworks@gmail.com \
--cc=chenhuacai@kernel.org \
--cc=dakr@kernel.org \
--cc=dianders@chromium.org \
--cc=driver-core@lists.linux.dev \
--cc=ekffu200098@gmail.com \
--cc=enju.kohei@fujitsu.com \
--cc=florian.fainelli@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshan@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=james.morse@arm.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=osandov@fb.com \
--cc=praan@google.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=ryan.roberts@arm.com \
--cc=sdonthineni@nvidia.com \
--cc=skolothumtho@nvidia.com \
--cc=smostafa@google.com \
--cc=sonangp@nvidia.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tan.shaopeng@jp.fujitsu.com \
--cc=thuth@redhat.com \
--cc=tzimmermann@suse.de \
--cc=vsethi@nvidia.com \
--cc=wenst@chromium.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 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.