All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.