mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@linux.intel.com>
To: kvm@vger.kernel.org, sumit.semwal@linaro.org,
	christian.koenig@amd.com, pbonzini@redhat.com, seanjc@google.com,
	alex.williamson@redhat.com, jgg@nvidia.com,
	dan.j.williams@intel.com, aik@amd.com,
	linux-coco@lists.linux.dev
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, vivek.kasireddy@intel.com,
	yilun.xu@intel.com, yilun.xu@linux.intel.com,
	linux-kernel@vger.kernel.org, lukas@wunner.de,
	yan.y.zhao@intel.com, daniel.vetter@ffwll.ch, leon@kernel.org,
	baolu.lu@linux.intel.com, zhenzhong.duan@intel.com,
	tao1.su@intel.com, linux-pci@vger.kernel.org, zhiw@nvidia.com,
	simona.vetter@ffwll.ch, shameerali.kolothum.thodi@huawei.com,
	aneesh.kumar@kernel.org, iommu@lists.linux.dev,
	kevin.tian@intel.com
Subject: [RFC PATCH 18/30] iommufd/viommu: Add trusted IOMMU configuration handlers for vdev
Date: Thu, 29 May 2025 13:35:01 +0800	[thread overview]
Message-ID: <20250529053513.1592088-19-yilun.xu@linux.intel.com> (raw)
In-Reply-To: <20250529053513.1592088-1-yilun.xu@linux.intel.com>

Add handlers for setting up/removing trusted IOMMU configurations
against vdevice. IOMMUFD calls these handlers on TSM bind/unbind. Most
vendors extend the trusted IOMMU engine for private device assignment,
thus require extra IOMMU configuration for TSM bind. E.g. Intel TDX
Connect requires host to build extra trusted Device Conext Table
entries (but not present), while AMD requires to clear Domain-ID on
non-secure DTE.

Existing DMA setup flow against IOMMUFD are driven by userspace, usually
start with allocating a domain, then attach the domain to the device.
While trusted DMA setup is embedded in TSM bind/unbind() IOCTLs. This is
because platform secure firmwares have various configuration
enforcements for trusted. E.g. Intel TDX Connect enforces trusted IOPT
detach after TDI STOP but before TDI metadata free. Using coarser uAPIs
like TSM bind/unbind that wrap all trusted configurations prevent these
low level complexities propagating to userspace.

Coarser uAPI means userspace lose the flexibility to attach different
domains to trusted part of the device. Also it cannot operate on the
trusted domain. That seems not a problem cause VMM is out of the TCB so
secure firmware either disallows VMM touching the trusted domain or only
allows a fixed configuration set. E.g. TDX Connect enforces all assigned
devices in the same VM must share the same trusted domain. It also
specifies every value of the trusted Context Table entries. So just
setup everything for trusted DMA in IOMMU driver is a reasonable choice.

OPEN: Should these handlers be viommu ops or vdevice ops?

Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
---
 drivers/iommu/iommufd/iommufd_private.h |  1 +
 drivers/iommu/iommufd/viommu.c          | 41 ++++++++++++++++++++++++-
 include/linux/iommufd.h                 |  2 ++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
index 29af8616e4aa..0db9a0e53a77 100644
--- a/drivers/iommu/iommufd/iommufd_private.h
+++ b/drivers/iommu/iommufd/iommufd_private.h
@@ -618,6 +618,7 @@ struct iommufd_vdevice {
 	u64 id; /* per-vIOMMU virtual ID */
 	struct mutex tsm_lock;
 	bool tsm_bound;
+	bool trusted_dma_enabled;
 };
 
 int iommufd_vdevice_tsm_bind(struct iommufd_vdevice *vdev);
diff --git a/drivers/iommu/iommufd/viommu.c b/drivers/iommu/iommufd/viommu.c
index 296143e21368..8437e936c278 100644
--- a/drivers/iommu/iommufd/viommu.c
+++ b/drivers/iommu/iommufd/viommu.c
@@ -224,6 +224,37 @@ int iommufd_vdevice_alloc_ioctl(struct iommufd_ucmd *ucmd)
 	return rc;
 }
 
+static int iommufd_vdevice_enable_trusted_dma(struct iommufd_vdevice *vdev)
+{
+	struct iommufd_viommu *viommu = vdev->viommu;
+	int rc;
+
+	if (vdev->trusted_dma_enabled)
+		return 0;
+
+	if (viommu->ops->setup_trusted_vdev) {
+		rc = viommu->ops->setup_trusted_vdev(viommu, vdev->id);
+		if (rc)
+			return rc;
+	}
+
+	vdev->trusted_dma_enabled = true;
+	return 0;
+}
+
+static void iommufd_vdevice_disable_trusted_dma(struct iommufd_vdevice *vdev)
+{
+	struct iommufd_viommu *viommu = vdev->viommu;
+
+	if (!vdev->trusted_dma_enabled)
+		return;
+
+	if (viommu->ops->remove_trusted_vdev)
+		viommu->ops->remove_trusted_vdev(viommu, vdev->id);
+
+	vdev->trusted_dma_enabled = false;
+}
+
 int iommufd_vdevice_tsm_bind(struct iommufd_vdevice *vdev)
 {
 	struct kvm *kvm;
@@ -241,12 +272,19 @@ int iommufd_vdevice_tsm_bind(struct iommufd_vdevice *vdev)
 		goto out_unlock;
 	}
 
-	rc = pci_tsm_bind(to_pci_dev(vdev->dev), kvm, vdev->id);
+	rc = iommufd_vdevice_enable_trusted_dma(vdev);
 	if (rc)
 		goto out_unlock;
 
+	rc = pci_tsm_bind(to_pci_dev(vdev->dev), kvm, vdev->id);
+	if (rc)
+		goto out_disable_trusted_dma;
+
 	vdev->tsm_bound = true;
+	goto out_unlock;
 
+out_disable_trusted_dma:
+	iommufd_vdevice_disable_trusted_dma(vdev);
 out_unlock:
 	mutex_unlock(&vdev->tsm_lock);
 	return rc;
@@ -259,6 +297,7 @@ void iommufd_vdevice_tsm_unbind(struct iommufd_vdevice *vdev)
 		goto out_unlock;
 
 	pci_tsm_unbind(to_pci_dev(vdev->dev));
+	iommufd_vdevice_disable_trusted_dma(vdev);
 	vdev->tsm_bound = false;
 
 out_unlock:
diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
index 5f9a286232ac..d73e8d3b9b95 100644
--- a/include/linux/iommufd.h
+++ b/include/linux/iommufd.h
@@ -136,6 +136,8 @@ struct iommufd_viommu_ops {
 		const struct iommu_user_data *user_data);
 	int (*cache_invalidate)(struct iommufd_viommu *viommu,
 				struct iommu_user_data_array *array);
+	int (*setup_trusted_vdev)(struct iommufd_viommu *viommu, u64 vdev_id);
+	void (*remove_trusted_vdev)(struct iommufd_viommu *viommu, u64 vdev_id);
 };
 
 #if IS_ENABLED(CONFIG_IOMMUFD)
-- 
2.25.1


  parent reply	other threads:[~2025-05-29  5:43 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-29  5:34 [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 01/30] HACK: dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 02/30] vfio: Export vfio device get and put registration helpers Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 03/30] vfio/pci: Share the core device pointer while invoking feature functions Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 04/30] vfio/pci: Allow MMIO regions to be exported through dma-buf Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 05/30] fixup! vfio/pci: fix dma-buf revoke typo on reset Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 06/30] HACK: vfio/pci: Support get_pfn() callback for dma-buf Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 07/30] KVM: Support vfio_dmabuf backed MMIO region Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 08/30] KVM: x86/mmu: Handle page fault for vfio_dmabuf backed MMIO Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 09/30] KVM: x86/mmu: Handle page fault for private MMIO Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 10/30] vfio/pci: Export vfio dma-buf specific info for importers Xu Yilun
2025-06-02 13:30   ` Jason Gunthorpe
2025-06-03  5:01     ` Xu Yilun
2026-07-12  1:01     ` Ackerley Tng
2026-07-12 22:19       ` Jason Gunthorpe
2026-07-13 23:16         ` Ackerley Tng
2026-07-13 19:08       ` Fuad Tabba
2026-07-13 19:17         ` Jason Gunthorpe
2026-07-13 22:40           ` Ackerley Tng
2026-07-14  6:38           ` Fuad Tabba
2025-05-29  5:34 ` [RFC PATCH 11/30] KVM: vfio_dmabuf: Fetch VFIO specific dma-buf data for sanity check Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 12/30] iommufd/device: Associate a kvm pointer to iommufd_device Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 13/30] fixup! iommufd/selftest: Sync iommufd_device_bind() change to selftest Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 14/30] iommu/arm-smmu-v3-iommufd: Pass in kvm pointer to viommu_alloc Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 15/30] fixup: iommu/selftest: Sync .viommu_alloc() change to selftest Xu Yilun
2025-05-29  5:34 ` [RFC PATCH 16/30] iommufd/viommu: track the kvm pointer & its refcount in viommu core Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 17/30] iommufd/device: Add TSM Bind/Unbind for TIO support Xu Yilun
2025-06-02 12:43   ` Aneesh Kumar K.V
2025-06-03  6:20     ` Xu Yilun
2025-06-03 12:21       ` Jason Gunthorpe
2025-06-04  8:40         ` Aneesh Kumar K.V
2025-06-04 13:24           ` Jason Gunthorpe
2025-06-06  7:59             ` Aneesh Kumar K.V
2025-05-29  5:35 ` Xu Yilun [this message]
2025-05-29  5:35 ` [RFC PATCH 19/30] vfio/pci: Add TSM TDI bind/unbind IOCTLs for TEE-IO support Xu Yilun
2025-06-01 10:45   ` Aneesh Kumar K.V
2025-06-02 14:43     ` Xu Yilun
2025-06-04 13:37       ` Aneesh Kumar K.V
2025-06-05  9:41         ` Xu Yilun
2025-06-05 15:09           ` Jason Gunthorpe
2025-06-06  3:25             ` Xu Yilun
2025-06-05 16:09           ` Aneesh Kumar K.V
2025-06-16  8:16           ` Aneesh Kumar K.V
2025-06-18  4:54             ` Xu Yilun
2025-06-05 12:03   ` Aneesh Kumar K.V
2025-06-05 15:10     ` Jason Gunthorpe
2025-06-05 16:17       ` Aneesh Kumar K.V
2025-06-05 16:33         ` Jason Gunthorpe
2025-06-06  4:26           ` Xu Yilun
2025-06-06  9:32           ` Aneesh Kumar K.V
2025-06-06 12:09             ` Jason Gunthorpe
2025-05-29  5:35 ` [RFC PATCH 20/30] vfio/pci: Do TSM Unbind before zapping bars Xu Yilun
2025-06-02  5:20   ` Aneesh Kumar K.V
2025-06-02 13:56     ` Xu Yilun
2025-06-02 14:00   ` Aneesh Kumar K.V
2025-06-03  4:50     ` Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 21/30] iommufd/vdevice: Add TSM Guest request uAPI Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 22/30] fixup! PCI/TSM: Change the guest request type definition Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 23/30] coco/tdx_tsm: Introduce a "tdx" subsystem and "tsm" device Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 24/30] coco/tdx_tsm: TEE Security Manager driver for TDX Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 25/30] coco/tdx_tsm: Add connect()/disconnect() handlers prototype Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 26/30] coco/tdx_tsm: Add bind()/unbind()/guest_req() " Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 27/30] PCI/TSM: Add PCI driver callbacks to handle TSM requirements Xu Yilun
2025-06-02 13:06   ` Aneesh Kumar K.V
2025-06-03  5:52     ` Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 28/30] vfio/pci: Implement TSM handlers for MMIO Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 29/30] iommufd/vdevice: Implement TSM handlers for trusted DMA Xu Yilun
2025-05-29  5:35 ` [RFC PATCH 30/30] coco/tdx_tsm: Manage TDX Module enforced operation sequences for Unbind Xu Yilun
2025-06-02 13:37 ` [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Jason Gunthorpe
2025-06-20  4:21   ` Xu Yilun
2025-06-11  1:55 ` Alexey Kardashevskiy
2025-06-21  1:07   ` Alexey Kardashevskiy
2025-06-25 10:45     ` Xu Yilun
2025-07-11 23:08       ` dan.j.williams
2025-07-15 11:09         ` Jonathan Cameron

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=20250529053513.1592088-19-yilun.xu@linux.intel.com \
    --to=yilun.xu@linux.intel.com \
    --cc=aik@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=tao1.su@intel.com \
    --cc=vivek.kasireddy@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yilun.xu@intel.com \
    --cc=zhenzhong.duan@intel.com \
    --cc=zhiw@nvidia.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