mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: iommu@lists.linux.dev, x86@kernel.org,
	linux-coco@lists.linux.dev, kvm@vger.kernel.org
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	yilun.xu@linux.intel.com, xiaoyao.li@intel.com,
	Chao Gao <chao.gao@intel.com>,
	Binbin Wu <binbin.wu@linux.intel.com>,
	linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com>
Subject: [PATCH v2 0/4] coco/tdx-host: Introduce trusted DMA initialization support
Date: Thu, 15 Oct 2026 09:07:01 +0800	[thread overview]
Message-ID: <20261015010705.1973284-1-baolu.lu@linux.intel.com> (raw)

Hi,

This series adds trusted DMA initialization support to the tdx-host and
intel-iommu drivers, as groundwork for TEE I/O trusted DMA support.

Following Jason Gunthorpe's suggestion on v1, this version moves the
host/TDX-module interactions out of the IOMMU driver and into the TDX
host (TSM) driver. It is posted to collect review feedback from TDX, TSM
and IOMMU stakeholders; it is not yet intended for merging.

This is part of the effort to implement the TDX PCIe Link Encryption
feature, which includes the following components:

[ ] TDX module extensions initialization, posted in [3]
[X] Introduce trusted DMA initialization support
[ ] SEAMCALL helpers for TDX PCIe Link Encryption
[ ] PCIe Link Encryption Establishment via TDX platform services

Background:

Intel VT-d hardware gains a second set of DMA translation structures,
owned by the TDX module and used only for devices assigned to
confidential guests.

From the TDX Connect architecture perspective, VT-d is enhanced with:

  1) Trusted DMA translation root table
     - A second root-table address register, restricted to SEAM SAI.
     - Programmed by the TDX module with the root of TDX-managed DMA
       translation tables for TD-assigned devices.

  2) Trusted invalidation queue
     - A second invalidation-queue address register plus dedicated
       head/tail registers, also restricted to SEAM SAI.

  3) IOTLB / DID isolation
     - When TDX Connect is enabled, the TDX module owns the half of the
       domain ID space with the MSB set; the VMM must confine itself to
       the lower half.

This posting covers initialization only: the host hands the TDX module
the memory it needs and asks it to take over trusted DMA management on
each capable IOMMU. The non-trusted DMA path is unchanged, except that
the host's usable domain ID space on TDX-capable IOMMUs is halved. The
TDX guest and device flows come in a later series.

Breakdown:

- Patch 1: Adds the TDH.IOMMU.SETUP and TDH.IOMMU.CLEAR SEAMCALL
  wrappers, exported only to the tdx-host module.

- Patch 2: Reads the IOMMU_MT_PAGES_COUNT global metadata field when
  TDX_FEATURES0 advertises TDX Connect. It tells the host how many
  metadata pages the TDX module needs per IOMMU.

- Patch 3: Adds dmar_tdxcs_iommu_init_all() and
  dmar_tdxcs_iommu_release() to the VT-d driver. init_all() walks the
  active DMAR units, checks the preconditions TDH.IOMMU.SETUP requires,
  confines the host to the lower half of the DID space, and hands each
  TDX-capable unit to a tdx-host callback.

- Patch 4: Implements the setup() callback in the tdx-host driver:
  allocates the trusted invalidation-queue buffers and metadata pages
  on the IOMMU's NUMA node, builds the IOMMU_MT parameter page, and
  issues TDH.IOMMU.SETUP. Units the TDX module does not cover are
  skipped. Teardown uses TDH.IOMMU.CLEAR; if that fails, the pages are
  intentionally leaked.

Change log:

v2:
- Moved the TDX module interactions (page allocation, IOMMU_MT
  construction, SEAMCALLs) from the VT-d driver to the tdx-host driver.
  The VT-d driver now only does the DRHD walk, precondition checks and
  DID reservation, and exposes them via a callback-based API.
- Renamed tdx-host.c to main.c and added iommu.c.

v1:
- https://lore.kernel.org/r/20260915074235.1219183-1-baolu.lu@linux.intel.com

ABI History:

TDH.IOMMU.CLEAR previously required the host to provide, as input, the
parameter page used for TDH.IOMMU.SETUP. The ABI has changed to take
only the TDX IOMMU ID. This change is not yet reflected in the public
ABI specification [1], so the two may differ.

Reference:

Implementation details follow the interfaces and behavior defined in the
TDX Connect Application Binary Interface (ABI) Reference Specification
and Intel TDX Connect Architecture Specification [1].

A full preview of these dependencies and follow-up changes is available
at [4].

Link: https://cdrdv2.intel.com/v1/dl/getContent/858625 # [1]
Link: https://www.intel.com/content/www/us/en/content-details/862706/intel-tdx-connect-architecture-specification.html # [2]
Link: https://lore.kernel.org/r/20261013-tdx-module-ext-v4-0-de5ffac65470@linux.intel.com # [3]
Link: https://github.com/intel-staging/tdx/tree/tdisp_phase1 # [4]

Please review. Any feedback is highly appreciated.

Thanks,
Baolu

Lu Baolu (4):
  x86/virt/tdx: Add SEAMCALL wrappers for IOMMU setup/clear
  x86/virt/tdx: Read global metadata for trusted IOMMU
  iommu/vt-d: Add an API for tdx-host when enabling trusted DMA
  coco/tdx-host: Initialize trusted DMA on all capable IOMMUs

 drivers/virt/coco/tdx-host/Kconfig            |   6 +
 drivers/virt/coco/tdx-host/Makefile           |   3 +
 arch/x86/include/asm/tdx.h                    |   3 +
 arch/x86/include/asm/tdx_global_metadata.h    |   5 +
 arch/x86/virt/vmx/tdx/tdx.h                   |   2 +
 drivers/iommu/intel/iommu.h                   |   6 +
 drivers/virt/coco/tdx-host/private.h          |  33 +++
 include/linux/dmar.h                          |   5 +
 arch/x86/virt/vmx/tdx/tdx.c                   |  56 ++++
 arch/x86/virt/vmx/tdx/tdx_global_metadata.c   |  20 ++
 drivers/iommu/intel/dmar.c                    | 103 +++++++
 drivers/iommu/intel/iommu.c                   |  19 ++
 drivers/virt/coco/tdx-host/iommu.c            | 255 ++++++++++++++++++
 .../virt/coco/tdx-host/{tdx-host.c => main.c} |  21 +-
 14 files changed, 536 insertions(+), 1 deletion(-)
 create mode 100644 drivers/virt/coco/tdx-host/private.h
 create mode 100644 drivers/virt/coco/tdx-host/iommu.c
 rename drivers/virt/coco/tdx-host/{tdx-host.c => main.c} (92%)

-- 
2.43.0


             reply	other threads:[~2026-10-15  1:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15  1:07 Lu Baolu [this message]
2026-10-15  1:07 ` [PATCH v2 1/4] x86/virt/tdx: Add SEAMCALL wrappers for IOMMU setup/clear Lu Baolu
2026-10-15  6:34   ` Xu Yilun
2026-10-15  1:07 ` [PATCH v2 2/4] x86/virt/tdx: Read global metadata for trusted IOMMU Lu Baolu
2026-10-15  6:47   ` Xu Yilun
2026-10-15  1:07 ` [PATCH v2 3/4] iommu/vt-d: Add an API for tdx-host when enabling trusted DMA Lu Baolu
2026-10-15  1:07 ` [PATCH v2 4/4] coco/tdx-host: Initialize trusted DMA on all capable IOMMUs Lu Baolu
2026-10-15  8:31   ` Xu Yilun
2026-10-15 17:37     ` Jason Gunthorpe

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=20261015010705.1973284-1-baolu.lu@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=kas@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=yilun.xu@linux.intel.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

all inboxes | Powered by JetHome®