* RE: [PATCH v5 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Michael Kelley @ 2026-05-26 4:30 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86@kernel.org
In-Reply-To: <20260522042815.370873-1-aneesh.kumar@kernel.org>
From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Sent: Thursday, May 21, 2026 9:28 PM
>
> This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
> dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
> are handled consistently.
>
> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
> shared/decrypted buffer handling. This series consolidates the
> force_dma_unencrypted() checks in the top-level functions and ensures
> that the remaining DMA interfaces use DMA attributes to make the correct
> decisions.
>
> The series:
> - moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
> - propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free
> paths
> - teaches the atomic DMA pools to track encrypted versus decrypted
> state
> - tracks swiotlb pool encryption state and enforces strict pool
> selection
> - centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
> DMA attributes
> - passes DMA attributes down to dma_capable() so capability checks can
> validate whether the selected DMA address encoding matches
> DMA_ATTR_CC_SHARED
> - makes dma_direct_map_phys() choose the DMA address encoding from
> DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
> cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
> relying on SWIOTLB_FORCE for DMA mappings
> - use the selected swiotlb pool state to derive the returned DMA
> address.
[snip]
>
>
> Aneesh Kumar K.V (Arm) (20):
> [DO NOT MERGE] arm64/coco: Add pKVM as a CC platform
> [DO NOT MERGE] s390: Expose protected virtualization through
> cc_platform_has()
> dma-direct: swiotlb: handle swiotlb alloc/free outside
> __dma_direct_alloc_pages
> dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
> dma-pool: track decrypted atomic pools and select them via attrs
> dma: swiotlb: pass mapping attributes by reference
> dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
> dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
> dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
> dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
> dma-direct: set decrypted flag for remapped DMA allocations
> dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED
> dma-pool: fix page leak in atomic_pool_expand() cleanup
> dma-direct: rename ret to cpu_addr in alloc helpers
> dma-direct: return struct page from dma_direct_alloc_from_pool()
> iommu/dma: Check atomic pool allocation result directly
> dma: swiotlb: free dynamic pools from process context
> dma: swiotlb: handle set_memory_decrypted() failures
> dma: free atomic pool pages by physical address
> swiotlb: Preserve allocation virtual address for dynamic pools
>
> arch/arm64/include/asm/hypervisor.h | 6 +
> arch/arm64/include/asm/mem_encrypt.h | 3 +-
> arch/arm64/kernel/rsi.c | 12 -
> arch/arm64/mm/init.c | 17 +-
> arch/powerpc/platforms/pseries/svm.c | 2 +-
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 16 +-
> arch/x86/kernel/amd_gart_64.c | 30 +-
> arch/x86/kernel/pci-dma.c | 4 +-
> drivers/iommu/dma-iommu.c | 15 +-
> drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c | 5 +
> drivers/xen/swiotlb-xen.c | 8 +-
> include/linux/dma-direct.h | 20 +-
> include/linux/dma-map-ops.h | 3 +-
> include/linux/swiotlb.h | 20 +-
> kernel/dma/direct.c | 275 +++++++++++++-----
> kernel/dma/direct.h | 47 +--
> kernel/dma/mapping.c | 16 +-
> kernel/dma/pool.c | 221 ++++++++++----
> kernel/dma/swiotlb.c | 270 +++++++++++++----
> 20 files changed, 717 insertions(+), 274 deletions(-)
>
I tested the series in a linux-next20260518 kernel, running in an
Azure VM on the Hyper-V hypervisor. The physical processor is Intel
XEON(R) PLATINUM 8573C with TDX memory encryption in use, so
this is a Linux CoCo VM. The VM has the usual VMBus synthetic disk
and network devices provided by Hyper-V, plus two PCI NVMe devices
that are directly assigned to the VM. I did basic smoke tests in the
VM, including reading and writing the NVMe devices. The swiotlb is
used as expected for DMA transfers to/from the synthetic and NVMe
devices. The NVMe driver does dma_alloc_coherent() to allocate
memory for control structures that must be decrypted. I did "unbind"
on the NVMe devices, and then rebound them so the dma allocations
would be freed and then reallocated. All looks good.
I'd like to try the same tests in a CoCo VM based on AMD SEV-SNP,
but I need to get quota for that VM size in Azure, and I don't know
how soon that can happen.
So as described above,
Tested-by: Michael Kelley <mhklinux@outlook.com>
^ permalink raw reply
* Re: [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put()
From: Chao Gao @ 2026-05-26 8:57 UTC (permalink / raw)
To: Rick Edgecombe
Cc: bp, dave.hansen, hpa, kas, kvm, linux-coco, linux-doc,
linux-kernel, mingo, nik.borisov, pbonzini, seanjc, tglx,
vannapurve, x86, yan.y.zhao, kai.huang, Kirill A. Shutemov
In-Reply-To: <20260526023515.288829-7-rick.p.edgecombe@intel.com>
On Mon, May 25, 2026 at 07:35:10PM -0700, Rick Edgecombe wrote:
>@@ -2057,32 +2057,50 @@ static int tdx_pamt_get(kvm_pfn_t pfn)
> if (!tdx_supports_dynamic_pamt(&tdx_sysinfo))
> return 0;
>
>+ pamt_refcount = tdx_find_pamt_refcount(pfn);
>+
>+ /*
>+ * If the pamt page is already added (i.e. refcount >= 1),
>+ * then just increment the refcount.
>+ */
>+ if (atomic_inc_not_zero(pamt_refcount))
>+ return 0;
>+
> ret = alloc_pamt_array(pamt_pages);
> if (ret)
> return ret;
>
>- pamt_refcount = tdx_find_pamt_refcount(pfn);
>+ spin_lock(&pamt_lock);
>
>- scoped_guard(spinlock, &pamt_lock) {
This converts the scoped_guard() added by the previous patch to
explicit lock/unlock and goto. It would reduce code churn if the
previous patch used that form directly.
>- /*
>- * If the pamt page is already added (i.e. refcount >= 1),
>- * then just increment the refcount.
>- */
>- if (atomic_read(pamt_refcount)) {
>- atomic_inc(pamt_refcount);
>- goto out_free;
>- }
>-
>- /* Try to add the pamt page and take the refcount 0->1. */
>- tdx_status = tdh_phymem_pamt_add(pfn, pamt_pages);
>- if (WARN_ON_ONCE(tdx_status != TDX_SUCCESS)) {
>- ret = -EIO;
>- goto out_free;
>- }
>-
>- atomic_set(pamt_refcount, 1);
>+ /*
>+ * Unlike tdx_pamt_put() which uses atomic_dec_and_lock() to
>+ * atomically handle the 1->0 transition, the get side has no
>+ * equivalent combined primitive for 0->1. Recheck under the
>+ * lock since another get may have already done the 0->1
>+ * transition after both saw atomic_inc_not_zero() fail.
>+ */
>+ if (atomic_read(pamt_refcount)) {
>+ atomic_inc(pamt_refcount);
>+ spin_unlock(&pamt_lock);
>+ goto out_free;
> }
>
>+ tdx_status = tdh_phymem_pamt_add(pfn, pamt_pages);
>+ if (tdx_status == TDX_SUCCESS) {
>+ /*
>+ * The refcount is zero, and this locked path is the
>+ * only way to increase it from 0->1.
>+ */
>+ atomic_set(pamt_refcount, 1);
>+ } else {
>+ WARN_ON_ONCE(1);
>+ ret = -EIO;
>+ spin_unlock(&pamt_lock);
>+ goto out_free;
>+ }
>+
>+ spin_unlock(&pamt_lock);
>+
> return 0;
> out_free:
> free_pamt_array(pamt_pages);
>@@ -2104,32 +2122,34 @@ static void tdx_pamt_put(kvm_pfn_t pfn)
>
> pamt_refcount = tdx_find_pamt_refcount(pfn);
>
>- scoped_guard(spinlock, &pamt_lock) {
Ditto
>+ /*
>+ * If there is more than 1 reference on the pamt page, don't
>+ * remove it yet. Just decrement the refcount.
>+ */
>+ if (!atomic_dec_and_lock(pamt_refcount, &pamt_lock))
>+ return;
>+
>+ tdx_status = tdh_phymem_pamt_remove(pfn, pamt_pages);
>+
>+ /*
>+ * Don't free pamt_pages as it could hold garbage when
>+ * tdh_phymem_pamt_remove() fails. Don't panic/BUG_ON(), as
>+ * there is no risk of data corruption, but do yell loudly as
>+ * failure indicates a kernel bug, memory is being leaked, and
>+ * the dangling PAMT entry may cause future operations to fail.
>+ */
>+ if (WARN_ON_ONCE(tdx_status != TDX_SUCCESS)) {
> /*
>- * If the there are more than 1 references on the pamt page,
>- * don't remove it yet. Just decrement the refcount.
>+ * atomic_dec_and_lock() already decremented it to 0,
>+ * but the PAMT entry still exists since REMOVE failed.
> */
>- if (atomic_read(pamt_refcount) > 1) {
>- atomic_dec(pamt_refcount);
>- return;
>- }
>-
>- /* Try to remove the pamt page and take the refcount 1->0. */
>- tdx_status = tdh_phymem_pamt_remove(pfn, pamt_pages);
>-
>- /*
>- * Don't free pamt_pages as it could hold garbage when
>- * tdh_phymem_pamt_remove() fails. Don't panic/BUG_ON(), as
>- * there is no risk of data corruption, but do yell loudly as
>- * failure indicates a kernel bug, memory is being leaked, and
>- * the dangling PAMT entry may cause future operations to fail.
>- */
>- if (WARN_ON_ONCE(tdx_status != TDX_SUCCESS))
>- return;
>-
>- atomic_set(pamt_refcount, 0);
>+ atomic_set(pamt_refcount, 1);
>+ spin_unlock(&pamt_lock);
>+ return;
> }
>
>+ spin_unlock(&pamt_lock);
>+
> free_pamt_array(pamt_pages);
> }
>
>--
>2.54.0
>
^ permalink raw reply
* Re: [RFC PATCH 15/15] x86/virt/tdx: Enable TDX Quoting extension
From: Tony Lindgren @ 2026-05-26 9:00 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Xu Yilun, kas, djbw, rick.p.edgecombe, x86, peter.fang,
linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan
In-Reply-To: <892508b2-6c61-4db2-a12f-902f62385e71@intel.com>
On Mon, May 25, 2026 at 06:51:27PM +0800, Xiaoyao Li wrote:
> On 5/25/2026 1:17 PM, Tony Lindgren wrote:
> > On Fri, May 22, 2026 at 11:41:28AM +0800, Xu Yilun wrote:
> > > From: Peter Fang <peter.fang@intel.com>
> > >
> > > TDX Module updates global metadata when add-on features are enabled.
> > > Host should update the cached tdx_sysinfo to reflect these changes.
> >
> > This should be made clearer IMO. How about mention that get_tdx_sys_info()
> > needs to get called again to reload the TDX module global metadata?
>
> Ah ha! This patch answers my comment to patch 1:
> https://lore.kernel.org/all/956fa1e6-2920-4b2e-8037-d4b9d812ae53@intel.com/
>
> sysinfo_ext->memory_pool_required_pages and sysinfo_ext->ext_required will
> be updated after extensions are enabled by TDH.SYS.CONFIG.
>
> Patch 06 in this series already reads the tdx_sys_info_quote out of
> get_tdx_sys_info(), which mean get_tdx_sys_info() doesn't ensure all the
> global metadata will be update again.
>
> So how about move the read of memory_pool_required_pages and ext_required
> out of get_tdx_sys_info() and put them after TDH.SYS.CONFIG, so that we
> don't need call get_tdx_sys_info() again?
Sounds like a good idea to me.
^ permalink raw reply
* Re: [PATCH v5 1/5] vfio: cache KVM VM file references instead of raw struct kvm pointers
From: Anthony Krowiak @ 2026-05-26 10:52 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-coco, iommu, linux-kernel, kvm
Cc: Alexey Kardashevskiy, Bjorn Helgaas, Dan Williams,
Jason Gunthorpe, Joerg Roedel, Jonathan Cameron, Kevin Tian,
Nicolin Chen, Samuel Ortiz, Steven Price, Suzuki K Poulose,
Will Deacon, Xu Yilun, Shameer Kolothum, Paolo Bonzini,
Halil Pasic, Jason Herne, Harald Freudenberger, Holger Dengler,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Alex Williamson,
Matthew Rosato, Farhan Ali, Eric Farman, linux-s390
In-Reply-To: <20260525154816.1029642-2-aneesh.kumar@kernel.org>
On 5/25/26 11:48 AM, Aneesh Kumar K.V (Arm) wrote:
> VFIO currently records struct kvm pointers on vfio_group, vfio_device_file
> and the opened vfio_device. Switch VFIO to track the VM's struct file
> instead, so VFIO and iommufd can use normal file references for VM lifetime
> instead of depending on KVM's internal struct kvm refcounting.
>
> KVM_CREATE_DEVICE binds the KVM VM lifetime to the KVM device fd lifetime.
> For KVM_DEV_TYPE_VFIO, the KVM VFIO device fd also takes references to each
> VFIO file added through KVM_DEV_VFIO_FILE_ADD. The KVM VFIO device fd
> therefore owns both the internal KVM reference and the VFIO file references
> in kvf->file.
>
> KVM_DEV_VFIO_FILE_ADD further installs the VM file association into the
> VFIO file. VFIO converts the struct kvm pointer to a VM file reference with
> get_file_active(&kvm->_file), because the KVM device fd can keep struct kvm
> alive after the original VM fd is already in final release.
>
> The association intentionally pins the VM file until KVM_DEV_VFIO_FILE_DEL
> or until the KVM VFIO device fd is released. This gives VFIO/iommufd a
> stable VM file reference source without taking a dependency on KVM's struct
> kvm lifetime. The KVM VFIO device release path clears the VFIO-side
> association before dropping its VFIO file references.
>
> When a VFIO device is opened or bound, VFIO takes an additional reference
> from the associated VM file and stores it in vfio_device::kvm_file for
> driver and iommufd use. That open-time reference is released from
> vfio_device_put_kvm() when the VFIO device is closed or unbound.
>
> This gives the ownership model:
>
> - KVM device fd pins struct kvm through kvm->users_count
> - KVM VFIO device fd pins VFIO files through kvf->file
> - VFIO group/device-file state pins the VM file while associated with KVM
> - vfio_device::kvm_file pins the VM file during active VFIO device use
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Acked-by: Anthony Krowiak <akrowiak@linxux.ibm.com>
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 5 +-
> drivers/vfio/device_cdev.c | 10 ++--
> drivers/vfio/group.c | 14 +++---
> drivers/vfio/pci/vfio_pci_zdev.c | 7 +--
> drivers/vfio/vfio.h | 16 ++++--
> drivers/vfio/vfio_main.c | 81 ++++++++++++++++---------------
> include/linux/kvm_host.h | 3 ++
> include/linux/vfio.h | 17 ++++++-
> virt/kvm/kvm_main.c | 2 +
> 9 files changed, 91 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 44b3a1dcc1b3..05996a8fd860 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -2054,11 +2054,12 @@ static int vfio_ap_mdev_open_device(struct vfio_device *vdev)
> {
> struct ap_matrix_mdev *matrix_mdev =
> container_of(vdev, struct ap_matrix_mdev, vdev);
> + struct kvm *kvm = vfio_device_get_kvm(vdev);
>
> - if (!vdev->kvm)
> + if (!kvm)
> return -EINVAL;
>
> - return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm);
> + return vfio_ap_mdev_set_kvm(matrix_mdev, kvm);
> }
>
> static void vfio_ap_mdev_close_device(struct vfio_device *vdev)
> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> index 54abf312cf04..ca75ab8eb7bd 100644
> --- a/drivers/vfio/device_cdev.c
> +++ b/drivers/vfio/device_cdev.c
> @@ -56,7 +56,7 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
> static void vfio_df_get_kvm_safe(struct vfio_device_file *df)
> {
> spin_lock(&df->kvm_ref_lock);
> - vfio_device_get_kvm_safe(df->device, df->kvm);
> + vfio_device_get_kvm_safe(df->device, df->kvm_file);
> spin_unlock(&df->kvm_ref_lock);
> }
>
> @@ -133,10 +133,10 @@ long vfio_df_ioctl_bind_iommufd(struct vfio_device_file *df,
> }
>
> /*
> - * Before the device open, get the KVM pointer currently
> - * associated with the device file (if there is) and obtain
> - * a reference. This reference is held until device closed.
> - * Save the pointer in the device for use by drivers.
> + * Before the device open, get the VM struct file currently
> + * associated with the device file (if there is one) and obtain a
> + * reference. This reference is held until the device is closed.
> + * Save the file in the device for use by drivers.
> */
> vfio_df_get_kvm_safe(df);
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index b2299e5bc6df..8950cfb9405d 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -163,7 +163,7 @@ static int vfio_group_ioctl_set_container(struct vfio_group *group,
> static void vfio_device_group_get_kvm_safe(struct vfio_device *device)
> {
> spin_lock(&device->group->kvm_ref_lock);
> - vfio_device_get_kvm_safe(device, device->group->kvm);
> + vfio_device_get_kvm_safe(device, device->group->kvm_file);
> spin_unlock(&device->group->kvm_ref_lock);
> }
>
> @@ -181,10 +181,10 @@ static int vfio_df_group_open(struct vfio_device_file *df)
> mutex_lock(&device->dev_set->lock);
>
> /*
> - * Before the first device open, get the KVM pointer currently
> - * associated with the group (if there is one) and obtain a reference
> - * now that will be held until the open_count reaches 0 again. Save
> - * the pointer in the device for use by drivers.
> + * Before the first device open, get the VM struct file currently
> + * associated with the group (if there is one) and obtain a
> + * reference now that will be held until the open_count reaches 0
> + * again. Save the file in the device for use by drivers.
> */
> if (device->open_count == 0)
> vfio_device_group_get_kvm_safe(device);
> @@ -862,9 +862,7 @@ bool vfio_group_enforced_coherent(struct vfio_group *group)
>
> void vfio_group_set_kvm(struct vfio_group *group, struct kvm *kvm)
> {
> - spin_lock(&group->kvm_ref_lock);
> - group->kvm = kvm;
> - spin_unlock(&group->kvm_ref_lock);
> + vfio_kvm_file_replace(&group->kvm_file, &group->kvm_ref_lock, kvm);
> }
>
> /**
> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c
> index 0990fdb146b7..a9d8e6aa3839 100644
> --- a/drivers/vfio/pci/vfio_pci_zdev.c
> +++ b/drivers/vfio/pci/vfio_pci_zdev.c
> @@ -144,15 +144,16 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)
> {
> struct zpci_dev *zdev = to_zpci(vdev->pdev);
> + struct kvm *kvm = vfio_device_get_kvm(&vdev->vdev);
>
> if (!zdev)
> return -ENODEV;
>
> - if (!vdev->vdev.kvm)
> + if (!kvm)
> return 0;
>
> if (zpci_kvm_hook.kvm_register)
> - return zpci_kvm_hook.kvm_register(zdev, vdev->vdev.kvm);
> + return zpci_kvm_hook.kvm_register(zdev, kvm);
>
> return -ENOENT;
> }
> @@ -161,7 +162,7 @@ void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
> {
> struct zpci_dev *zdev = to_zpci(vdev->pdev);
>
> - if (!zdev || !vdev->vdev.kvm)
> + if (!zdev || !vfio_device_get_kvm(&vdev->vdev))
> return;
>
> if (zpci_kvm_hook.kvm_unregister)
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index e4b72e79b7e3..41032104eb36 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -22,8 +22,8 @@ struct vfio_device_file {
>
> u8 access_granted;
> u32 devid; /* only valid when iommufd is valid */
> - spinlock_t kvm_ref_lock; /* protect kvm field */
> - struct kvm *kvm;
> + spinlock_t kvm_ref_lock; /* protect kvm_file */
> + struct file *kvm_file;
> struct iommufd_ctx *iommufd; /* protected by struct vfio_device_set::lock */
> };
>
> @@ -88,7 +88,7 @@ struct vfio_group {
> #endif
> enum vfio_group_type type;
> struct mutex group_lock;
> - struct kvm *kvm;
> + struct file *kvm_file;
> struct file *opened_file;
> struct iommufd_ctx *iommufd;
> spinlock_t kvm_ref_lock;
> @@ -434,11 +434,17 @@ static inline void vfio_virqfd_exit(void)
> #endif
>
> #if IS_ENABLED(CONFIG_KVM)
> -void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm);
> +void vfio_kvm_file_replace(struct file **dst, spinlock_t *lock, struct kvm *kvm);
> +void vfio_device_get_kvm_safe(struct vfio_device *device, struct file *kvm_file);
> void vfio_device_put_kvm(struct vfio_device *device);
> #else
> +static inline void vfio_kvm_file_replace(struct file **dst,
> + spinlock_t *lock, struct kvm *kvm)
> +{
> +}
> +
> static inline void vfio_device_get_kvm_safe(struct vfio_device *device,
> - struct kvm *kvm)
> + struct file *kvm_file)
> {
> }
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 6222376ab6ab..88c85a7b98c0 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -442,55 +442,61 @@ void vfio_unregister_group_dev(struct vfio_device *device)
> EXPORT_SYMBOL_GPL(vfio_unregister_group_dev);
>
> #if IS_ENABLED(CONFIG_KVM)
> -void vfio_device_get_kvm_safe(struct vfio_device *device, struct kvm *kvm)
> +void vfio_kvm_file_replace(struct file **dst, spinlock_t *lock, struct kvm *kvm)
> {
> - void (*pfn)(struct kvm *kvm);
> - bool (*fn)(struct kvm *kvm);
> - bool ret;
> + struct file *old_kvm_file, *new_kvm_file = NULL;
>
> - lockdep_assert_held(&device->dev_set->lock);
> + /*
> + * @kvm can outlive the VM fd and its final __fput(). Only take a
> + * new reference if the VM file is still active.
> + */
> + if (kvm)
> + new_kvm_file = get_file_active(&kvm->_file);
>
> - if (!kvm)
> - return;
> + spin_lock(lock);
> + old_kvm_file = *dst;
> + *dst = new_kvm_file;
> + spin_unlock(lock);
>
> - pfn = symbol_get(kvm_put_kvm);
> - if (WARN_ON(!pfn))
> - return;
> + if (old_kvm_file)
> + fput(old_kvm_file);
> +}
>
> - fn = symbol_get(kvm_get_kvm_safe);
> - if (WARN_ON(!fn)) {
> - symbol_put(kvm_put_kvm);
> - return;
> - }
> +void vfio_device_get_kvm_safe(struct vfio_device *device, struct file *kvm_file)
> +{
> + lockdep_assert_held(&device->dev_set->lock);
>
> - ret = fn(kvm);
> - symbol_put(kvm_get_kvm_safe);
> - if (!ret) {
> - symbol_put(kvm_put_kvm);
> - return;
> - }
> + /*
> + * Take a VM file reference if the KVM fd is still active.
> + */
> + if (kvm_file)
> + kvm_file = get_file(kvm_file);
>
> - device->put_kvm = pfn;
> - device->kvm = kvm;
> + device->kvm_file = kvm_file;
> }
>
> void vfio_device_put_kvm(struct vfio_device *device)
> {
> + struct file *kvm_file;
> +
> lockdep_assert_held(&device->dev_set->lock);
>
> - if (!device->kvm)
> + kvm_file = device->kvm_file;
> + if (!kvm_file)
> return;
>
> - if (WARN_ON(!device->put_kvm))
> - goto clear;
> + device->kvm_file = NULL;
> + fput(kvm_file);
> +}
>
> - device->put_kvm(device->kvm);
> - device->put_kvm = NULL;
> - symbol_put(kvm_put_kvm);
> +struct kvm *vfio_device_get_kvm(struct vfio_device *device)
> +{
> + if (!device->kvm_file)
> + return NULL;
>
> -clear:
> - device->kvm = NULL;
> + return device->kvm_file->private_data;
> }
> +EXPORT_SYMBOL_GPL(vfio_device_get_kvm);
> #endif
>
> /* true if the vfio_device has open_device() called but not close_device() */
> @@ -1518,13 +1524,10 @@ static void vfio_device_file_set_kvm(struct file *file, struct kvm *kvm)
> struct vfio_device_file *df = file->private_data;
>
> /*
> - * The kvm is first recorded in the vfio_device_file, and will
> - * be propagated to vfio_device::kvm when the file is bound to
> - * iommufd successfully in the vfio device cdev path.
> + * Cache the VM file reference associated with this VFIO file so it
> + * can be pinned into vfio_device while the device is open.
> */
> - spin_lock(&df->kvm_ref_lock);
> - df->kvm = kvm;
> - spin_unlock(&df->kvm_ref_lock);
> + vfio_kvm_file_replace(&df->kvm_file, &df->kvm_ref_lock, kvm);
> }
>
> /**
> @@ -1532,8 +1535,8 @@ static void vfio_device_file_set_kvm(struct file *file, struct kvm *kvm)
> * @file: VFIO group file or VFIO device file
> * @kvm: KVM to link
> *
> - * When a VFIO device is first opened the KVM will be available in
> - * device->kvm if one was associated with the file.
> + * When a VFIO device is first opened, VFIO caches a VM file reference if
> + * one was associated with the file.
> */
> void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> {
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 4c14aee1fb06..31afac5fb0ea 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -45,6 +45,8 @@
> #include <asm/kvm_host.h>
> #include <linux/kvm_dirty_ring.h>
>
> +struct file;
> +
> #ifndef KVM_MAX_VCPU_IDS
> #define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
> #endif
> @@ -861,6 +863,7 @@ struct kvm {
> struct srcu_struct srcu;
> struct srcu_struct irq_srcu;
> pid_t userspace_pid;
> + struct file __rcu *_file;
> bool override_halt_poll_ns;
> unsigned int max_halt_poll_ns;
> u32 dirty_ring_size;
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 31b826efba00..bca1d00f7845 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -22,8 +22,22 @@ struct kvm;
> struct iommufd_ctx;
> struct iommufd_device;
> struct iommufd_access;
> +struct vfio_device;
> struct vfio_info_cap;
>
> +#if IS_ENABLED(CONFIG_KVM)
> +/*
> + * Return the KVM associated with @vdev's kvm_file. The returned pointer
> + * is valid only while VFIO device open holds the kvm_file reference.
> + */
> +struct kvm *vfio_device_get_kvm(struct vfio_device *vdev);
> +#else
> +static inline struct kvm *vfio_device_get_kvm(struct vfio_device *vdev)
> +{
> + return NULL;
> +}
> +#endif
> +
> /*
> * VFIO devices can be placed in a set, this allows all devices to share this
> * structure and the VFIO core will provide a lock that is held around
> @@ -54,7 +68,7 @@ struct vfio_device {
> struct list_head dev_set_list;
> unsigned int migration_flags;
> u8 precopy_info_v2;
> - struct kvm *kvm;
> + struct file *kvm_file;
>
> /* Members below here are private, not for driver use */
> unsigned int index;
> @@ -66,7 +80,6 @@ struct vfio_device {
> unsigned int open_count;
> struct completion comp;
> struct iommufd_access *iommufd_access;
> - void (*put_kvm)(struct kvm *kvm);
> struct inode *inode;
> #if IS_ENABLED(CONFIG_IOMMUFD)
> struct iommufd_device *iommufd_device;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89489996fbc1..011819c5c47c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1351,6 +1351,7 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
>
> kvm_irqfd_release(kvm);
>
> + RCU_INIT_POINTER(kvm->_file, NULL);
> kvm_put_kvm(kvm);
> return 0;
> }
> @@ -5500,6 +5501,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
> r = PTR_ERR(file);
> goto put_kvm;
> }
> + rcu_assign_pointer(kvm->_file, file);
>
> /*
> * Don't call kvm_put_kvm anymore at this point; file->f_op is
^ permalink raw reply
* Re: [PATCH v5 10/20] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-26 15:39 UTC (permalink / raw)
To: Michael Kelley
Cc: Aneesh Kumar K.V (Arm), iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <SN6PR02MB41574064D14D4A2734222C51D40B2@SN6PR02MB4157.namprd02.prod.outlook.com>
On Tue, May 26, 2026 at 02:56:57AM +0000, Michael Kelley wrote:
> With this patch removing SWIOTLB_FORCE from four places in
> kernel code, there are no remaining places where it is set.
> The test of SWIOTLB_FORCE could be removed from
> swiotlb_init_remap(), and its definition could be deleted
> from include/linux/swiotlb.h.
That's great! I think it shows this is the right approach!
Jason
^ permalink raw reply
* SVSM Development Call May 27th, 2026
From: Stefano Garzarella @ 2026-05-26 15:46 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
Here is the call for agenda items for this weeks SVSM development
call. Please send any agenda items you have in mind as a reply to this
email or raise them in the meeting.
We will use the LF Zoom instance. Details of the meeting can be found
in our governance repository at:
https://github.com/coconut-svsm/governance
The link to the COCONUT-SVSM calendar is:
https://zoom-lfx.platform.linuxfoundation.org/meetings/coconut-svsm?view=week
The meeting will be recorded and the recording eventually published.
Regards,
Stefano
^ permalink raw reply
* Re: [PATCH v2 2/5] KVM: guest_memfd: Fix possible signed integer overflow
From: Sean Christopherson @ 2026-05-26 15:53 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-2-3f196bfad5a1@google.com>
For shortlogs (and changeloges), when possible, describe the _change_ itself, not
its impact is. Sometimes "Fix xyz" is the best shortlog, e.g. when fixing build
failures, but here, I would go with:
KVM: guest_memfd: Treat memslot binding offset+size as unsigned values
for two reasons. First, it provides a lot more context for future readers, versus
"Fix possible signed integer overflow" which doesn't even capture what flow is
affected, how the overflow is being fixed, etc. Second, if the fix is wrong,
incomplete, etc., we don't end up with a follow-up patch that start with "Really
fix ...".
Oh, actually, three reasons. This doesn't only affect the overflow check. The
check on a negative offset is flawed, as it means KVM would incorrectly reject
bindings with (comically) large offsets.
LOL, four. There is no bug. The size of the memslot is ((1UL << 31) - 1)
pages, i.e. 0x7FF_FFFFF000:
if (id < KVM_USER_MEM_SLOTS &&
(mem->memory_size >> PAGE_SHIFT) > KVM_MEM_MAX_NR_PAGES)
return -EINVAL;
and so "loff_t size" can never be negative.
As for the offset, the negative check is intentional, because KVM_CREATE_GUEST_MEMFD
takes loff_t for the size, and so an offset that is negative would also be larger
than the size of the file.
I still think it's worth taking unsigned values, because teasing out all of that
information wasn't exactly easy.
On Fri, May 22, 2026, Ackerley Tng wrote:
> From: Sean Christopherson <seanjc@google.com>
>
> The caller, kvm_set_memory_region(), checks for an overflow in an unsigned
> u64 guest_memfd_offset. When guest_memfd_offset is passed to kvm_gmem_bind,
> it is cast into a signed 64-bit integer.
>
> Hence, a large 64-bit offset could result in a negative loff_t, which could
> result in the overflow checks failing.
>
> Make kvm_gmem_bind() take u64 instead of loff_t to consistently deal with
> unsigned values to avoid this issue.
>
> Fixes: a7800aa80ea4d ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> [Use size_t for size instead of u64]
Why? Oh, right, because kvm_memory_slot.npages is an "unsigned long". The
discrepancy between a u64 for the offset and a size_t for the size is confusing,
as they are both conceptually in the same "domain".
Rather than u64 and size_t, we should use pgoff_t, which is what KVM already uses
as the storage for kvm_memory_slot.gmem.pgoff.
I'll send a new version as a standalone patch.
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: SNP: Fix kunmap_local() unmapping order
From: Sean Christopherson @ 2026-05-26 15:55 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-4-3f196bfad5a1@google.com>
Similar comment on the shortlog as patch two. "Fix the order" tells the reader
nothing useful, other than the author of the patch thought there was a bug.
KVM: SEV: Unmap local kmaps in LIFO order, per highmem requirements
No need for a new version, I'll massage when applying.
On Fri, May 22, 2026, Ackerley Tng wrote:
> Mappings created with kmap_local_page() or kmap_local_pfn() must be
> unmapped in the reverse order they were acquired, following a LIFO
> (last-in, first-out) stack-based approach.
>
> In sev_gmem_post_populate(), src_vaddr is mapped first and dst_vaddr is
> mapped second. The current code incorrectly calls kunmap_local() for
> src_vaddr before dst_vaddr.
>
> Swap the kunmap_local() calls to ensure the mappings are released in the
> correct order.
It's worth calling out that this is completely benign since SNP is 64-bit only.
^ permalink raw reply
* Re: [RFC PATCH 15/15] x86/virt/tdx: Enable TDX Quoting extension
From: Xu Yilun @ 2026-05-26 15:45 UTC (permalink / raw)
To: Xiaoyao Li
Cc: Tony Lindgren, kas, djbw, rick.p.edgecombe, x86, peter.fang,
linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan
In-Reply-To: <892508b2-6c61-4db2-a12f-902f62385e71@intel.com>
On Mon, May 25, 2026 at 06:51:27PM +0800, Xiaoyao Li wrote:
> On 5/25/2026 1:17 PM, Tony Lindgren wrote:
> > On Fri, May 22, 2026 at 11:41:28AM +0800, Xu Yilun wrote:
> > > From: Peter Fang <peter.fang@intel.com>
> > >
> > > TDX Module updates global metadata when add-on features are enabled.
> > > Host should update the cached tdx_sysinfo to reflect these changes.
> >
> > This should be made clearer IMO. How about mention that get_tdx_sys_info()
> > needs to get called again to reload the TDX module global metadata?
>
> Ah ha! This patch answers my comment to patch 1:
> https://lore.kernel.org/all/956fa1e6-2920-4b2e-8037-d4b9d812ae53@intel.com/
>
> sysinfo_ext->memory_pool_required_pages and sysinfo_ext->ext_required will
> be updated after extensions are enabled by TDH.SYS.CONFIG.
>
> Patch 06 in this series already reads the tdx_sys_info_quote out of
> get_tdx_sys_info(), which mean get_tdx_sys_info() doesn't ensure all the
> global metadata will be update again.
>
> So how about move the read of memory_pool_required_pages and ext_required
> out of get_tdx_sys_info() and put them after TDH.SYS.CONFIG, so that we
> don't need call get_tdx_sys_info() again?
Yes, I'm good to it. I hesitated to move them out in case we need some
central control on global data. But now I see there is already a
precedent:
https://lore.kernel.org/kvm/20260520133909.409394-22-chao.gao@intel.com/
Once we've agreed on moving add-on data reading out of get_tdx_sys_info(),
we don't have to read them after TDH.SYS.CONFIG, read them when really
needed. How about the following, that makes the Extension part in this
series self-contained.
----8<----
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 86e5b7ad19b3..b729c1f5ab9e 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -1536,6 +1536,10 @@ static __init int init_tdx_ext(void)
if (!(tdx_sysinfo.features.tdx_features0 & TDX_FEATURES0_EXT))
return 0;
+ ret = get_tdx_sys_info_ext(&tdx_sysinfo.ext);
+ if (ret)
+ return ret;
+
/* No feature requires TDX Module Extensions. */
if (!tdx_sysinfo.ext.ext_required)
return 0;
diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
index f9cc2dd02caf..e7d9e0c4b604 100644
--- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
+++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
@@ -140,8 +140,5 @@ static __init int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
ret = ret ?: get_tdx_sys_info_td_conf(&sysinfo->td_conf);
- if (sysinfo->features.tdx_features0 & TDX_FEATURES0_EXT)
- ret = ret ?: get_tdx_sys_info_ext(&sysinfo->ext);
-
return ret;
}
^ permalink raw reply related
* Re: [PATCH v2 1/5] KVM: guest_memfd: Use write permissions when GUP-ing source pages
From: Sean Christopherson @ 2026-05-26 16:13 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-1-3f196bfad5a1@google.com>
The shortlog is misleading, bordering on outright wrong. I think most people
would read it as "ALWAYS Use write permissions when GUP-ing source pages". I
also think it should be scoped to:
KVM: SEV:
because this only affects SNP, and IMO is an SNP bug, not a guest_memfd bug. E.g.
KVM: SEV: Pin source page for write when adding CPUID data for SNP guest
On Fri, May 22, 2026, Ackerley Tng wrote:
> From: Sean Christopherson <seanjc@google.com>
>
> sev_gmem_post_populate() may write to the source page if there was an error
Avoid referencing function names in changelogs when possible. Unless the reader
is already familiar with the code, the name is meaningless. The purpose of the
changelog is to complement the literal patch, not to provide a play-by-play
description.
> while performing SNP_LAUNCH_UPDATE.
>
> Since GUP requested only reads, there is a chance sev_gmem_post_populate()
> could be writing to some read-only page.
>
> sev_gmem_post_populate() will only ever write the source page if the type
> of page being LAUNCH_UPDATEd is a CPUID page. Hence, request a writable
> page only when loading the CPUID page.
>
> Since TDX never writes to the source page, always pass false to
> kvm_gmem_populate().
Describe changes in human-friendly, conversational language. And in a way that
doesn't require looking at the patch to understand the changelog: "pass false"
is meaningless without looking at the code to see what flag was added (or exists).
> With this, even if a read-only mapping or the global zero page was provided
> as the source page, GUP will do a copy-on-write, making it writable before
> the write happens in gvm_post_populate.
Objection, speculation. If the mapping is truly read-only, i.e. doesn't allow
writes at all, then GUP will fail. This is all superfluous information though;
"read-only" is a pretty ubiquitous concept, there's no need to explain it in
gory detail.
I'll rewrite to this when applying:
---
When populating a guest_memfd instance with the initial CPUID data for an
SNP guest, acquire a writable pin on the source page as KVM will write back
the "correct" CPUID information if the userspace provided data is rejected
by trusted firmware. Because KVM writes to the source page using a kernel
mapping, pinning for read could result in KVM clobbering read-only memory.
Note, well-behaved VMMs are unlikely to be affected, as CPUID information
is almost always dynamically generated by userspace, i.e. it's unlikely for
the CPUID information to be backed by a read-only mapping.
---
> Fixes: 2a62345b30529 ("KVM: guest_memfd: GUP source pages prior to populating guest memory")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Cc: stable@vger.kernel.org
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
^ permalink raw reply
* Re: [PATCH v2 3/5] KVM: guest_memfd: Handle errors from xa_store_range() when binding
From: Sean Christopherson @ 2026-05-26 16:39 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-3-3f196bfad5a1@google.com>
On Fri, May 22, 2026, Ackerley Tng wrote:
> Unhandled errors from xa_store_range() means kvm_gmem_bind() might falsely
> reporting success, leading to false assumptions in guest_memfd's lifecycle
> later.
>
> On error, restore the unbound state and return the error to userspace.
>
> Fixes: a7800aa80ea4d ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> virt/kvm/guest_memfd.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index d203135969d13..5b4911ffa208a 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -648,6 +648,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
> struct inode *inode;
> struct file *file;
> int r = -EINVAL;
> + void *result;
I would rather go with "xr". "result" is too generic, e.g. begs the question of
"result of what?"
Actually, I don't think we even need an intermediate variable.
> BUILD_BUG_ON(sizeof(gfn_t) != sizeof(slot->gmem.pgoff));
>
> @@ -688,7 +689,14 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
> if (kvm_gmem_supports_mmap(inode))
> slot->flags |= KVM_MEMSLOT_GMEM_ONLY;
>
> - xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> + result = xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> + if (xa_is_err(result)) {
> + r = xa_err(result);
> + xa_store_range(&f->bindings, start, end - 1, NULL, GFP_KERNEL);
I'm not convinced this is necessary. Sashiko "asked" the question:
: If xa_store_range() fails midway through storing a large range (for example,
: returning -ENOMEM), does it leave the already-processed entries in the
: f->bindings XArray?
:
: When this error is propagated back, the caller __kvm_set_memory_region()
: will abort the operation and free the memslot without calling
: kvm_gmem_unbind().
:
: Since the partial XArray updates aren't rolled back here, could this leave
: dangling pointers to the freed memslot in f->bindings? If so, when the file
: is eventually closed, kvm_gmem_release() might iterate over these dangling
: pointers and write to slot->gmem.file, resulting in a use-after-free.
but I think Sashiko is hallicunating.
If @entry is non-NULL, xa_store_range() pre-creates the entire range, before
storing anything into the range:
if (entry) {
unsigned int order = BITS_PER_LONG;
if (last + 1)
order = __ffs(last + 1);
xas_set_order(&xas, last, order);
xas_create(&xas, true);
if (xas_error(&xas))
goto unlock;
}
Yes, the API handles failure on the subsequent xas_store(), but I can't imagine
that failure is actually, barring garbage input from KVM:
do {
xas_set_range(&xas, first, last);
xas_store(&xas, entry);
if (xas_error(&xas))
goto unlock;
first += xas_size(&xas);
} while (first <= last);
Purely from a design perspective, providing an API that can fail partway through
under normal operation, with no indication of where failure occured (AFAICT),
would be awful.
> + } else {
> + r = 0;
> + }
> +
> filemap_invalidate_unlock(inode->i_mapping);
>
> /*
> @@ -696,7 +704,6 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
> * not the other way 'round. Active bindings are invalidated if the
> * file is closed before memslots are destroyed.
> */
> - r = 0;
All in all, unless someone proves with a test that I'm wrong, just this?
diff --git virt/kvm/guest_memfd.c virt/kvm/guest_memfd.c
index 0c923fd603fd..c0f5b9565be2 100644
--- virt/kvm/guest_memfd.c
+++ virt/kvm/guest_memfd.c
@@ -688,7 +688,7 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
if (kvm_gmem_supports_mmap(inode))
slot->flags |= KVM_MEMSLOT_GMEM_ONLY;
- xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
+ r = xa_err(xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL));
filemap_invalidate_unlock(inode->i_mapping);
/*
@@ -696,7 +696,6 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot,
* not the other way 'round. Active bindings are invalidated if the
* file is closed before memslots are destroyed.
*/
- r = 0;
err:
fput(file);
return r;
^ permalink raw reply related
* Re: [PATCH v6 06/11] x86/virt/tdx: Optimize tdx_pamt_get/put()
From: Edgecombe, Rick P @ 2026-05-26 16:42 UTC (permalink / raw)
To: Gao, Chao
Cc: kvm@vger.kernel.org, linux-coco@lists.linux.dev, Huang, Kai,
Hansen, Dave, Zhao, Yan Y, kas@kernel.org, seanjc@google.com,
mingo@redhat.com, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, nik.borisov@suse.com,
linux-doc@vger.kernel.org, hpa@zytor.com, tglx@kernel.org,
Annapurve, Vishal, bp@alien8.de, kirill.shutemov@linux.intel.com,
x86@kernel.org
In-Reply-To: <ahVghgNAe4JrmlQH@intel.com>
On Tue, 2026-05-26 at 16:57 +0800, Chao Gao wrote:
> > - scoped_guard(spinlock, &pamt_lock) {
>
> This converts the scoped_guard() added by the previous patch to
> explicit lock/unlock and goto. It would reduce code churn if the
> previous patch used that form directly.
Yea, it's a good point. I actually debated doing it, but decided not to because
the scoped version is cleaner for the non-optimized version. But for
reviewability, never doing the scoped version is probably better.
^ permalink raw reply
* Re: [PATCH v2 5/5] KVM: SNP: Mark source page dirty in sev_gmem_post_populate
From: Sean Christopherson @ 2026-05-26 16:47 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-5-3f196bfad5a1@google.com>
On Fri, May 22, 2026, Ackerley Tng wrote:
> Mark the folio as dirty after copying data into the source page in
> sev_gmem_post_populate. After the memcpy, failing to mark the page dirty
> can lead to the memory management subsystem discarding the changes if the
> page is reclaimed or otherwise processed by the swap subsystem.
>
> Fixes: 2a62345b3052 ("KVM: guest_memfd: GUP source pages prior to populating guest memory")
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> arch/x86/kvm/svm/sev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index dbf75326a40f4..1a361f08c7a3d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -2395,6 +2395,7 @@ static int sev_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
> void *dst_vaddr = kmap_local_pfn(pfn);
>
> memcpy(src_vaddr, dst_vaddr, PAGE_SIZE);
> + folio_mark_dirty(page_folio(src_page));
I'd rather use set_page_dirty(). I'll fixup when applying, unless someon objects.
> kunmap_local(dst_vaddr);
> kunmap_local(src_vaddr);
>
> --
> 2.54.0.794.g4f17f83d09-goog
>
^ permalink raw reply
* Re: [PATCH v2 0/5] guest_memfd fixes for bind and populate
From: Sean Christopherson @ 2026-05-26 16:55 UTC (permalink / raw)
To: Ackerley Tng
Cc: Paolo Bonzini, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Kiryl Shutsemau, Rick Edgecombe,
Vishal Annapurve, Yan Zhao, Michael Roth, Isaku Yamahata,
Chao Peng, Xiaoyao Li, Zongyao Chen, kvm, linux-kernel,
linux-coco, Yu Zhang, Fuad Tabba
In-Reply-To: <20260522-fix-sev-gmem-post-populate-v2-0-3f196bfad5a1@google.com>
On Fri, May 22, 2026, Ackerley Tng wrote:
> This series is a group of fixes for the bind and populate flows for
> guest_memfd, and fixes some issues reported by Sashiko after reviewing the
> guest_memfd in-place conversions series [1] and another fixup series Sean
> posted [3].
In the future, please don't bundle unrelated changes. The SNP specific changes
are related and should be a series, but the signed integer thing and the lack of
error handling on xa_store_range() are completely unrelated, because the fact
that Sashiko kept complaining about pre-existing issues.
I totally understand why you bundled these together, but that obviously didn't
stop Sashiko from complaining about pre-existing issues, over and over.
Unnecessarily bundling can lead to exactly what's happening here: the three SNP
changes are ready to go, but the two unrelated guest_memfd changes need new
versions. Which isn't hard to deal with, but it's extra friction that is easily
avoided.
I'll apply the SNP changes, and send a new version of the signed vs. unsigned
issue. Please send a new version of the xa_store_range() error handling (or
prove that I'm wrong).
Thanks!
^ permalink raw reply
* Re: [PATCH v2 0/4] struct page to PFN conversion for TDX guest private memory
From: Sean Christopherson @ 2026-05-26 19:37 UTC (permalink / raw)
To: Yan Zhao
Cc: dave.hansen, pbonzini, tglx, mingo, bp, kas, x86, linux-kernel,
kvm, linux-coco, kai.huang, rick.p.edgecombe, yilun.xu,
vannapurve, ackerleytng, sagis, binbin.wu, xiaoyao.li,
isaku.yamahata
In-Reply-To: <20260430014852.24183-1-yan.y.zhao@intel.com>
On Thu, Apr 30, 2026, Yan Zhao wrote:
> Hi
>
> This is v2 of the struct page to PFN conversion series, which converts TDX
> guest private memory mapping/unmapping APIs from taking struct page to
> taking PFN as input.
>
> v2 is based on v7.1.0-rc1 + Sean's 4 cleanup patches (see details in
> section "Base" below). The purpose is to get Dave's Ack, so Sean can take
> it from the KVM x86 tree. The full stack of v2 is available at [14].
Dave, any concerns?
I'd like to get these into the KVM x86 tree sooner than later, so that we at
least have a fighting chance of landing the S-EPT cleanup (prep work for D-PAMT)
in 7.2.
^ permalink raw reply
* Re: [PATCH v2 0/4] struct page to PFN conversion for TDX guest private memory
From: Dave Hansen @ 2026-05-26 20:00 UTC (permalink / raw)
To: Sean Christopherson, Yan Zhao
Cc: dave.hansen, pbonzini, tglx, mingo, bp, kas, x86, linux-kernel,
kvm, linux-coco, kai.huang, rick.p.edgecombe, yilun.xu,
vannapurve, ackerleytng, sagis, binbin.wu, xiaoyao.li,
isaku.yamahata
In-Reply-To: <ahX2dcHAQgwuiJBC@google.com>
On 5/26/26 12:37, Sean Christopherson wrote:
>> v2 is based on v7.1.0-rc1 + Sean's 4 cleanup patches (see details in
>> section "Base" below). The purpose is to get Dave's Ack, so Sean can take
>> it from the KVM x86 tree. The full stack of v2 is available at [14].
> Dave, any concerns?
These look fine to me. They make the code marginally cleaner and the
changelogs are much better at describing the problem now.
Going to Linus via the KVM route is fine with me:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v14 13/44] arm64: RMI: Define the user ABI
From: Wei-Lin Chang @ 2026-05-26 22:17 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-14-steven.price@arm.com>
On Wed, May 13, 2026 at 02:17:21PM +0100, Steven Price wrote:
> There is one CAP which identified the presence of CCA, and one ioctl.
> The ioctl is used to populate memory during creation of the realm as
> this requires the RMM to copy data from an unprotected address to the
> protected memory - CCA does not support memory conversion where the
> memory contents is preserved as this is incompatible with memory
> encryption.
Nit:
I believe spelling out the CAP and ioctl names can improve the commit
message. Also "memory conversion" is a little vague, maybe
... CCA does not support shared <-> private memory conversion where ...
would make this clearer?
Thanks,
Wei-Lin Chang
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * KVM_ARM_VCPU_RMI_PSCI_COMPLETE removed.
> * KVM_ARM_RMI_POPULATE documentation updated to reflect that the
> structure is written by the kernel.
> * CAP number bumped.
> Changes since v12:
> * Change KVM_ARM_RMI_POPULATE to update the structure with the amount
> that has been progressed rather than return the number of bytes
> populated.
> * Describe the flag KVM_ARM_RMI_POPULATE_FLAGS_MEASURE.
> * CAP number is bumped.
> * NOTE: The PSCI ioctl may be removed in a future spec release.
> Changes since v11:
> * Completely reworked to be more implicit. Rather than having explicit
> CAP operations to progress the realm construction these operations
> are done when needed (on populating and on first vCPU run).
> * Populate and PSCI complete are promoted to proper ioctls.
> Changes since v10:
> * Rename symbols from RME to RMI.
> Changes since v9:
> * Improvements to documentation.
> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
> Changes since v8:
> * Minor improvements to documentation following review.
> * Bump the magic numbers to avoid conflicts.
> Changes since v7:
> * Add documentation of new ioctls
> * Bump the magic numbers to avoid conflicts
> Changes since v6:
> * Rename some of the symbols to make their usage clearer and avoid
> repetition.
> Changes from v5:
> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
> ---
> Documentation/virt/kvm/api.rst | 40 ++++++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 13 +++++++++++
> 2 files changed, 53 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce1..ca68aae7faa2 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6553,6 +6553,37 @@ KVM_S390_KEYOP_SSKE
> Sets the storage key for the guest address ``guest_addr`` to the key
> specified in ``key``, returning the previous value in ``key``.
>
> +4.145 KVM_ARM_RMI_POPULATE
> +--------------------------
> +
> +:Capability: KVM_CAP_ARM_RMI
> +:Architectures: arm64
> +:Type: vm ioctl
> +:Parameters: struct kvm_arm_rmi_populate (in/out)
> +:Returns: 0 on success, < 0 on error
> +
> +::
> +
> + struct kvm_arm_rmi_populate {
> + __u64 base;
> + __u64 size;
> + __u64 source_uaddr;
> + __u32 flags;
> + __u32 reserved;
> + };
> +
> +Populate a region of protected address space by copying the data from the
> +(non-protected) user space pointer provided into a protected region (backed by
> +guestmem_fd). It implicitly sets the destination region to RIPAS RAM. This is
> +only valid before any VCPUs have been run. The ioctl might not populate the
> +entire region and in this case the kernel updates the fields `base`, `size` and
> +`source_uaddr`. User space may have to repeatedly call it until `size` is 0 to
> +populate the entire region.
> +
> +`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request that the
> +populated data is hashed and added to the guest's Realm Initial Measurement
> +(RIM).
> +
> .. _kvm_run:
>
> 5. The kvm_run structure
> @@ -8904,6 +8935,15 @@ helpful if user space wants to emulate instructions which are not
> This capability can be enabled dynamically even if VCPUs were already
> created and are running.
>
> +7.47 KVM_CAP_ARM_RMI
> +--------------------
> +
> +:Architectures: arm64
> +:Target: VM
> +:Parameters: None
> +
> +This capability indicates that support for CCA realms is available.
> +
> 8. Other capabilities.
> ======================
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 6c8afa2047bf..b8cff0938041 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
> #define KVM_CAP_S390_USER_OPEREXEC 246
> #define KVM_CAP_S390_KEYOP 247
> #define KVM_CAP_S390_VSIE_ESAMODE 248
> +#define KVM_CAP_ARM_RMI 249
>
> struct kvm_irq_routing_irqchip {
> __u32 irqchip;
> @@ -1669,4 +1670,16 @@ struct kvm_pre_fault_memory {
> __u64 padding[5];
> };
>
> +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM */
> +#define KVM_ARM_RMI_POPULATE _IOWR(KVMIO, 0xd7, struct kvm_arm_rmi_populate)
> +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0)
> +
> +struct kvm_arm_rmi_populate {
> + __u64 base;
> + __u64 size;
> + __u64 source_uaddr;
> + __u32 flags;
> + __u32 reserved;
> +};
> +
> #endif /* __LINUX_KVM_H */
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v14 17/44] arm64: RMI: RTT tear down
From: Wei-Lin Chang @ 2026-05-26 22:27 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-18-steven.price@arm.com>
Hi,
On Wed, May 13, 2026 at 02:17:25PM +0100, Steven Price wrote:
> The RMM owns the stage 2 page tables for a realm, and KVM must request
> that the RMM creates/destroys entries as necessary. The physical pages
> to store the page tables are delegated to the realm as required, and can
> be undelegated when no longer used.
>
> Creating new RTTs is the easy part, tearing down is a little more
> tricky. The result of realm_rtt_destroy() can be used to effectively
> walk the tree and destroy the entries (undelegating pages that were
> given to the realm).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * Avoid the double call of kvm_free_stage2_pgd() by splitting the work
> across that and a new function kvm_realm_uninit_stage2() which is
> only called for realm guests.
> Changes since v12:
> * Simplify some functions now we know RMM page size is the same as the
> host's.
> Changes since v11:
> * Moved some code from earlier in the series to this one so that it's
> added when it's first used.
> Changes since v10:
> * RME->RMI rename.
> * Some code to handle freeing stage 2 PGD moved into this patch where
> it belongs.
> Changes since v9:
> * Add a comment clarifying that root level RTTs are not destroyed until
> after the RD is destroyed.
> Changes since v8:
> * Introduce free_rtt() wrapper which calls free_delegated_granule()
> followed by kvm_account_pgtable_pages(). This makes it clear where an
> RTT is being freed rather than just a delegated granule.
> Changes since v6:
> * Move rme_rtt_level_mapsize() and supporting defines from kvm_rme.h
> into rme.c as they are only used in that file.
> Changes since v5:
> * Rename some RME_xxx defines to do with page sizes as RMM_xxx - they are
> a property of the RMM specification not the RME architecture.
> Changes since v2:
> * Moved {alloc,free}_delegated_page() and ensure_spare_page() to a
> later patch when they are actually used.
> * Some simplifications now rmi_xxx() functions allow NULL as an output
> parameter.
> * Improved comments and code layout.
> ---
> arch/arm64/include/asm/kvm_rmi.h | 7 ++
> arch/arm64/kvm/mmu.c | 21 ++++-
> arch/arm64/kvm/rmi.c | 148 +++++++++++++++++++++++++++++++
> 3 files changed, 174 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 9de34983ee52..06ba0d4745c6 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -64,5 +64,12 @@ u32 kvm_realm_ipa_limit(void);
>
> int kvm_init_realm(struct kvm *kvm);
> void kvm_destroy_realm(struct kvm *kvm);
> +void kvm_realm_destroy_rtts(struct kvm *kvm);
> +
> +static inline bool kvm_realm_is_private_address(struct realm *realm,
> + unsigned long addr)
> +{
> + return !(addr & BIT(realm->ia_bits - 1));
> +}
>
> #endif /* __ASM_KVM_RMI_H */
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index ba8286472286..eb56d4e7f21a 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1024,9 +1024,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
> return err;
> }
>
> +static void kvm_realm_uninit_stage2(struct kvm_s2_mmu *mmu)
> +{
> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> + struct realm *realm = &kvm->arch.realm;
> +
> + if (kvm_realm_state(kvm) != REALM_STATE_ACTIVE)
> + return;
> +
> + write_lock(&kvm->mmu_lock);
> + kvm_stage2_unmap_range(mmu, 0, BIT(realm->ia_bits - 1), true);
> + write_unlock(&kvm->mmu_lock);
> + kvm_realm_destroy_rtts(kvm);
> +}
> +
> void kvm_uninit_stage2_mmu(struct kvm *kvm)
> {
> - kvm_free_stage2_pgd(&kvm->arch.mmu);
> + if (kvm_is_realm(kvm))
> + kvm_realm_uninit_stage2(&kvm->arch.mmu);
> + else
> + kvm_free_stage2_pgd(&kvm->arch.mmu);
> kvm_mmu_free_memory_cache(&kvm->arch.mmu.split_page_cache);
> }
>
> @@ -1103,7 +1120,7 @@ void stage2_unmap_vm(struct kvm *kvm)
> void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> {
> struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> - struct kvm_pgtable *pgt = NULL;
> + struct kvm_pgtable *pgt;
Is this included by accident?
>
> write_lock(&kvm->mmu_lock);
> pgt = mmu->pgt;
[...]
Thanks,
Wei-Lin Chang
^ permalink raw reply
* Re: [PATCH v14 17/44] arm64: RMI: RTT tear down
From: Wei-Lin Chang @ 2026-05-26 22:32 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-18-steven.price@arm.com>
Hi,
On Wed, May 13, 2026 at 02:17:25PM +0100, Steven Price wrote:
> The RMM owns the stage 2 page tables for a realm, and KVM must request
> that the RMM creates/destroys entries as necessary. The physical pages
> to store the page tables are delegated to the realm as required, and can
> be undelegated when no longer used.
>
> Creating new RTTs is the easy part, tearing down is a little more
> tricky. The result of realm_rtt_destroy() can be used to effectively
> walk the tree and destroy the entries (undelegating pages that were
> given to the realm).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * Avoid the double call of kvm_free_stage2_pgd() by splitting the work
> across that and a new function kvm_realm_uninit_stage2() which is
> only called for realm guests.
> Changes since v12:
> * Simplify some functions now we know RMM page size is the same as the
> host's.
> Changes since v11:
> * Moved some code from earlier in the series to this one so that it's
> added when it's first used.
> Changes since v10:
> * RME->RMI rename.
> * Some code to handle freeing stage 2 PGD moved into this patch where
> it belongs.
> Changes since v9:
> * Add a comment clarifying that root level RTTs are not destroyed until
> after the RD is destroyed.
> Changes since v8:
> * Introduce free_rtt() wrapper which calls free_delegated_granule()
> followed by kvm_account_pgtable_pages(). This makes it clear where an
> RTT is being freed rather than just a delegated granule.
> Changes since v6:
> * Move rme_rtt_level_mapsize() and supporting defines from kvm_rme.h
> into rme.c as they are only used in that file.
> Changes since v5:
> * Rename some RME_xxx defines to do with page sizes as RMM_xxx - they are
> a property of the RMM specification not the RME architecture.
> Changes since v2:
> * Moved {alloc,free}_delegated_page() and ensure_spare_page() to a
> later patch when they are actually used.
> * Some simplifications now rmi_xxx() functions allow NULL as an output
> parameter.
> * Improved comments and code layout.
> ---
> arch/arm64/include/asm/kvm_rmi.h | 7 ++
> arch/arm64/kvm/mmu.c | 21 ++++-
> arch/arm64/kvm/rmi.c | 148 +++++++++++++++++++++++++++++++
> 3 files changed, 174 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 9de34983ee52..06ba0d4745c6 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -64,5 +64,12 @@ u32 kvm_realm_ipa_limit(void);
>
> int kvm_init_realm(struct kvm *kvm);
> void kvm_destroy_realm(struct kvm *kvm);
> +void kvm_realm_destroy_rtts(struct kvm *kvm);
> +
> +static inline bool kvm_realm_is_private_address(struct realm *realm,
> + unsigned long addr)
> +{
> + return !(addr & BIT(realm->ia_bits - 1));
> +}
>
> #endif /* __ASM_KVM_RMI_H */
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index ba8286472286..eb56d4e7f21a 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1024,9 +1024,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
> return err;
> }
>
> +static void kvm_realm_uninit_stage2(struct kvm_s2_mmu *mmu)
> +{
> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> + struct realm *realm = &kvm->arch.realm;
> +
> + if (kvm_realm_state(kvm) != REALM_STATE_ACTIVE)
> + return;
> +
> + write_lock(&kvm->mmu_lock);
> + kvm_stage2_unmap_range(mmu, 0, BIT(realm->ia_bits - 1), true);
> + write_unlock(&kvm->mmu_lock);
> + kvm_realm_destroy_rtts(kvm);
> +}
> +
> void kvm_uninit_stage2_mmu(struct kvm *kvm)
> {
> - kvm_free_stage2_pgd(&kvm->arch.mmu);
> + if (kvm_is_realm(kvm))
> + kvm_realm_uninit_stage2(&kvm->arch.mmu);
> + else
> + kvm_free_stage2_pgd(&kvm->arch.mmu);
> kvm_mmu_free_memory_cache(&kvm->arch.mmu.split_page_cache);
> }
>
> @@ -1103,7 +1120,7 @@ void stage2_unmap_vm(struct kvm *kvm)
> void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> {
> struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> - struct kvm_pgtable *pgt = NULL;
> + struct kvm_pgtable *pgt;
>
> write_lock(&kvm->mmu_lock);
> pgt = mmu->pgt;
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index f51ec667445e..5b00ccca4af3 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -11,6 +11,14 @@
> #include <asm/rmi_cmds.h>
> #include <asm/virt.h>
>
> +static inline unsigned long rmi_rtt_level_mapsize(int level)
> +{
> + if (WARN_ON(level > KVM_PGTABLE_LAST_LEVEL))
> + return PAGE_SIZE;
> +
> + return (1UL << ARM64_HW_PGTABLE_LEVEL_SHIFT(level));
> +}
> +
> static bool rmi_has_feature(unsigned long feature)
> {
> return !!u64_get_bits(rmm_feat_reg0, feature);
> @@ -21,6 +29,144 @@ u32 kvm_realm_ipa_limit(void)
> return u64_get_bits(rmm_feat_reg0, RMI_FEATURE_REGISTER_0_S2SZ);
> }
>
> +static int get_start_level(struct realm *realm)
> +{
> + return 4 - stage2_pgtable_levels(realm->ia_bits);
> +}
> +
> +static void free_rtt(phys_addr_t phys)
> +{
> + if (free_delegated_page(phys))
> + return;
> +
> + kvm_account_pgtable_pages(phys_to_virt(phys), -1);
> +}
> +
> +/*
> + * realm_rtt_destroy - Destroy an RTT at @level for @addr.
> + *
> + * Returns - Result of the RMI_RTT_DESTROY call, and:
> + * @rtt_granule: RTT granule, if the RTT was destroyed.
> + * @next_addr: IPA corresponding to the next possible valid entry we
> + * can target
> + */
> +static int realm_rtt_destroy(struct realm *realm, unsigned long addr,
> + int level, phys_addr_t *rtt_granule,
> + unsigned long *next_addr)
> +{
> + unsigned long out_rtt;
> + int ret;
> +
> + ret = rmi_rtt_destroy(virt_to_phys(realm->rd), addr, level,
> + &out_rtt, next_addr);
> +
> + *rtt_granule = out_rtt;
> +
> + return ret;
> +}
Looks like out_rtt can be simplified out.
[...]
Thanks,
Wei-Lin Chang
^ permalink raw reply
* Re: [PATCH v14 19/44] arm64: RMI: Allocate/free RECs to match vCPUs
From: Wei-Lin Chang @ 2026-05-26 22:39 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-20-steven.price@arm.com>
Hi,
On Wed, May 13, 2026 at 02:17:27PM +0100, Steven Price wrote:
> The RMM maintains a data structure known as the Realm Execution Context
> (or REC). It is similar to struct kvm_vcpu and tracks the state of the
> virtual CPUs. KVM must delegate memory and request the structures are
> created when vCPUs are created, and suitably tear down on destruction.
>
> RECs may require additional pages (e.g. for storing larger register
> state for SVE). The RMM can request extra pages for this purpose using
> the Stateful RMI Operations (SRO) functionality to request pages during
> REC creation. These pages are then passed back to the host from the RMM
> ('reclaimed') when the REC is destroyed. The kernel tracking object
> (struct rmi_sro_state) is stored in the realm_rec structure to avoid
> memory allocation during the destruction path.
>
> Note that only some of register state for the REC can be set by KVM, the
> rest is defined by the RMM (zeroed). The register state then cannot be
> changed by KVM after the REC is created (except when the guest
> explicitly requests this e.g. by performing a PSCI call).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * Support SRO for REC creation/destruction instead of auxiliary
> granules.
> Changes since v12:
> * Use the new range-based delegation RMI.
> Changes since v11:
> * Remove the KVM_ARM_VCPU_REC feature. User space no longer needs to
> configure each VCPU separately, RECs are created on the first VCPU
> run of the guest.
> Changes since v9:
> * Size the aux_pages array according to the PAGE_SIZE of the host.
> Changes since v7:
> * Add comment explaining the aux_pages array.
> * Rename "undeleted_failed" variable to "should_free" to avoid a
> confusing double negative.
> Changes since v6:
> * Avoid reporting the KVM_ARM_VCPU_REC feature if the guest isn't a
> realm guest.
> * Support host page size being larger than RMM's granule size when
> allocating/freeing aux granules.
> Changes since v5:
> * Separate the concept of vcpu_is_rec() and
> kvm_arm_vcpu_rec_finalized() by using the KVM_ARM_VCPU_REC feature as
> the indication that the VCPU is a REC.
> Changes since v2:
> * Free rec->run earlier in kvm_destroy_realm() and adapt to previous patches.
> ---
> arch/arm64/include/asm/kvm_emulate.h | 2 +-
> arch/arm64/include/asm/kvm_host.h | 3 +
> arch/arm64/include/asm/kvm_rmi.h | 17 +++++
> arch/arm64/kvm/arm.c | 6 ++
> arch/arm64/kvm/reset.c | 1 +
> arch/arm64/kvm/rmi.c | 105 +++++++++++++++++++++++++++
> 6 files changed, 133 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 82fd777bd9bb..2e69fe494716 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -714,7 +714,7 @@ static inline bool kvm_realm_is_created(struct kvm *kvm)
>
> static inline bool vcpu_is_rec(const struct kvm_vcpu *vcpu)
> {
> - return false;
> + return kvm_is_realm(vcpu->kvm);
> }
>
> #endif /* __ARM64_KVM_EMULATE_H__ */
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 3512696ed506..39b5de03d0fe 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -969,6 +969,9 @@ struct kvm_vcpu_arch {
>
> /* Hyp-readable copy of kvm_vcpu::pid */
> pid_t pid;
> +
> + /* Realm meta data */
> + struct realm_rec rec;
> };
>
> /*
> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h
> index 8bd743093ccf..d99bf4fc3c39 100644
> --- a/arch/arm64/include/asm/kvm_rmi.h
> +++ b/arch/arm64/include/asm/kvm_rmi.h
> @@ -59,6 +59,22 @@ struct realm {
> unsigned int ia_bits;
> };
>
> +/**
> + * struct realm_rec - Additional per VCPU data for a Realm
> + *
> + * @mpidr: MPIDR (Multiprocessor Affinity Register) value to identify this VCPU
> + * @rec_page: Kernel VA of the RMM's private page for this REC
> + * @aux_pages: Additional pages private to the RMM for this REC
> + * @run: Kernel VA of the RmiRecRun structure shared with the RMM
> + * @sro: A preallocated SRO state context
> + */
> +struct realm_rec {
> + unsigned long mpidr;
> + void *rec_page;
> + struct rec_run *run;
> + struct rmi_sro_state *sro;
> +};
> +
> void kvm_init_rmi(void);
> u32 kvm_realm_ipa_limit(void);
>
> @@ -66,6 +82,7 @@ int kvm_init_realm(struct kvm *kvm);
> int kvm_activate_realm(struct kvm *kvm);
> void kvm_destroy_realm(struct kvm *kvm);
> void kvm_realm_destroy_rtts(struct kvm *kvm);
> +void kvm_destroy_rec(struct kvm_vcpu *vcpu);
>
> static inline bool kvm_realm_is_private_address(struct realm *realm,
> unsigned long addr)
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index eb2b61fe1f0a..93d34762db91 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -586,6 +586,8 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
> /* Force users to call KVM_ARM_VCPU_INIT */
> vcpu_clear_flag(vcpu, VCPU_INITIALIZED);
>
> + vcpu->arch.rec.mpidr = INVALID_HWID;
> +
> vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO;
>
> /* Set up the timer */
> @@ -1651,6 +1653,10 @@ static int kvm_vcpu_init_check_features(struct kvm_vcpu *vcpu,
> if (test_bit(KVM_ARM_VCPU_HAS_EL2, &features))
> return -EINVAL;
>
> + /* Realms are incompatible with AArch32 */
> + if (vcpu_is_rec(vcpu))
> + return -EINVAL;
> +
> return 0;
> }
>
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index b963fd975aac..c18cdca7d125 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -161,6 +161,7 @@ void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
> free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
> kfree(vcpu->arch.vncr_tlb);
> kfree(vcpu->arch.ccsidr);
> + kvm_destroy_rec(vcpu);
> }
>
> static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 849111817af7..353a5ca45e78 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -173,9 +173,108 @@ static int realm_ensure_created(struct kvm *kvm)
> return -ENXIO;
> }
>
> +static int kvm_create_rec(struct kvm_vcpu *vcpu)
> +{
> + struct user_pt_regs *vcpu_regs = vcpu_gp_regs(vcpu);
> + unsigned long mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
> + struct realm *realm = &vcpu->kvm->arch.realm;
> + struct realm_rec *rec = &vcpu->arch.rec;
> + unsigned long rec_page_phys;
> + struct rec_params *params;
> + int r, i;
> +
> + if (rec->run)
> + return -EBUSY;
> +
> + /*
> + * The RMM will report PSCI v1.0 to Realms and the KVM_ARM_VCPU_PSCI_0_2
> + * flag covers v0.2 and onwards.
> + */
> + if (!vcpu_has_feature(vcpu, KVM_ARM_VCPU_PSCI_0_2))
> + return -EINVAL;
> +
> + BUILD_BUG_ON(sizeof(*params) > PAGE_SIZE);
> + BUILD_BUG_ON(sizeof(*rec->run) > PAGE_SIZE);
> +
> + params = (struct rec_params *)get_zeroed_page(GFP_KERNEL);
> + rec->rec_page = (void *)__get_free_page(GFP_KERNEL);
> + rec->run = (void *)get_zeroed_page(GFP_KERNEL);
Should this be cast to (struct rec_run *) ?
> + rec->sro = kmalloc_obj(*rec->sro);
> + if (!params || !rec->rec_page || !rec->run || !rec->sro) {
> + r = -ENOMEM;
> + goto out_free_pages;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(params->gprs); i++)
> + params->gprs[i] = vcpu_regs->regs[i];
> +
> + params->pc = vcpu_regs->pc;
> +
> + if (vcpu->vcpu_id == 0)
> + params->flags |= REC_PARAMS_FLAG_RUNNABLE;
> +
> + rec_page_phys = virt_to_phys(rec->rec_page);
> +
> + if (rmi_delegate_page(rec_page_phys)) {
> + r = -ENXIO;
> + goto out_free_pages;
> + }
> +
> + params->mpidr = mpidr;
> +
> + if (rmi_rec_create(virt_to_phys(realm->rd), rec_page_phys,
> + virt_to_phys(params), rec->sro)) {
> + r = -ENXIO;
> + goto out_undelegate_rmm_rec;
> + }
> +
> + rec->mpidr = mpidr;
> +
> + free_page((unsigned long)params);
> + return 0;
> +
> +out_undelegate_rmm_rec:
> + if (WARN_ON(rmi_undelegate_page(rec_page_phys)))
> + rec->rec_page = NULL;
> +out_free_pages:
> + free_page((unsigned long)rec->run);
> + free_page((unsigned long)rec->rec_page);
> + free_page((unsigned long)params);
> + kfree(rec->sro);
> + rec->run = NULL;
> + return r;
> +}
> +
[...]
Thanks,
Wei-Lin Chang
^ permalink raw reply
* Re: [PATCH v14 28/44] arm64: RMI: Create the realm descriptor
From: Wei-Lin Chang @ 2026-05-26 22:47 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-29-steven.price@arm.com>
Hi,
On Wed, May 13, 2026 at 02:17:36PM +0100, Steven Price wrote:
> Creating a realm involves first creating a realm descriptor (RD). This
> involves passing the configuration information to the RMM. Do this as
> part of realm_ensure_created() so that the realm is created when it is
> first needed.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * The RMM no longer uses AUX granules, so no need to ask it how many it
> needs.
> * Adapted to other changes.
> Changes since v12:
> * Since RMM page size is now equal to the host's page size various
> calculations are simplified.
> * Switch to using range based APIs to delegate/undelegate.
> * VMID handling is now handled entirely by the RMM.
> ---
> arch/arm64/kvm/rmi.c | 88 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index fb96bcaa73ed..cae29fd3353c 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -418,6 +418,77 @@ static void realm_unmap_shared_range(struct kvm *kvm,
> start, end);
> }
>
> +static int realm_create_rd(struct kvm *kvm)
> +{
> + struct realm *realm = &kvm->arch.realm;
> + struct realm_params *params = realm->params;
> + void *rd = NULL;
> + phys_addr_t rd_phys, params_phys;
> + size_t pgd_size = kvm_pgtable_stage2_pgd_size(kvm->arch.mmu.vtcr);
> + int r;
> +
> + realm->ia_bits = VTCR_EL2_IPA(kvm->arch.mmu.vtcr);
> +
> + if (WARN_ON(realm->rd || !realm->params))
> + return -EEXIST;
> +
> + rd = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
> + if (!rd)
> + return -ENOMEM;
> +
> + rd_phys = virt_to_phys(rd);
> + if (rmi_delegate_page(rd_phys)) {
> + r = -ENXIO;
> + goto free_rd;
> + }
> +
> + if (rmi_delegate_range(kvm->arch.mmu.pgd_phys, pgd_size)) {
> + r = -ENXIO;
> + goto out_undelegate_tables;
> + }
> +
> + params->s2sz = VTCR_EL2_IPA(kvm->arch.mmu.vtcr);
> + params->rtt_level_start = get_start_level(realm);
> + params->rtt_num_start = pgd_size / PAGE_SIZE;
> + params->rtt_base = kvm->arch.mmu.pgd_phys;
> +
> + if (kvm->arch.arm_pmu) {
> + params->pmu_num_ctrs = kvm->arch.nr_pmu_counters;
> + params->flags |= RMI_REALM_PARAM_FLAG_PMU;
> + }
> +
> + if (kvm_lpa2_is_enabled())
> + params->flags |= RMI_REALM_PARAM_FLAG_LPA2;
> +
> + params_phys = virt_to_phys(params);
> +
> + if (rmi_realm_create(rd_phys, params_phys)) {
> + r = -ENXIO;
> + goto out_undelegate_tables;
> + }
> +
> + realm->rd = rd;
> + kvm_set_realm_state(kvm, REALM_STATE_NEW);
> + /* The realm is up, free the parameters. */
> + free_page((unsigned long)realm->params);
> + realm->params = NULL;
> +
> + return 0;
> +
> +out_undelegate_tables:
> + if (WARN_ON(rmi_undelegate_range(kvm->arch.mmu.pgd_phys, pgd_size))) {
> + /* Leak the pages if they cannot be returned */
> + kvm->arch.mmu.pgt = NULL;
> + }
> + if (WARN_ON(rmi_undelegate_page(rd_phys))) {
> + /* Leak the page if it isn't returned */
> + return r;
> + }
> +free_rd:
> + free_page((unsigned long)rd);
> + return r;
> +}
> +
> static void realm_unmap_private_range(struct kvm *kvm,
> unsigned long start,
> unsigned long end,
> @@ -647,8 +718,21 @@ static int realm_init_ipa_state(struct kvm *kvm,
>
> static int realm_ensure_created(struct kvm *kvm)
> {
> - /* Provided in later patch */
> - return -ENXIO;
> + int ret;
> +
> + switch (kvm_realm_state(kvm)) {
> + case REALM_STATE_NONE:
> + break;
> + case REALM_STATE_NEW:
> + return 0;
> + case REALM_STATE_DEAD:
> + return -ENXIO;
> + default:
> + return -EBUSY;
> + }
> +
> + ret = realm_create_rd(kvm);
> + return ret;
> }
I think ret can be simplified out.
Thanks,
Wei-Lin Chang
>
> static int set_ripas_of_protected_regions(struct kvm *kvm)
> --
> 2.43.0
>
^ permalink raw reply
* [Invitation] bi-weekly guest_memfd upstream call on 2026-05-28
From: Ackerley Tng @ 2026-05-26 23:49 UTC (permalink / raw)
To: linux-coco, linux-mm, kvm; +Cc: david
Hi,
Our next guest_memfd upstream call is scheduled for Thursday, 2026-05-28
at 8:00 - 9:00am (GMT-07:00) Pacific Time - Vancouver.
We'll be using the following Google meet:
http://meet.google.com/wxp-wtju-jzw
In this meeting, we'll Tarun talk about guest_memfd preservation for
LiveUpdate.
We also have one question regarding virtio-mem and CoCo forwarded from
David.
The meeting notes can be found at [1], where we also link recordings and
collect current guest_memfd upstream proposals. If you want an google
calendar invitation that also covers all future meetings, just write
Ackerley or David a mail.
To put something to discuss onto the agenda, reply to this mail or add
them to the "Topics/questions for next meeting(s)" section in the
meeting notes as a comment.
[1] https://docs.google.com/document/d/1M6766BzdY1Lhk7LiR5IqVR8B8mG3cr-cxTxOrAosPOk/edit?usp=sharing
Ackerley
^ permalink raw reply
* Re: [PATCH v5 5/5] iommufd/vdevice: add TSM request ioctl
From: Alexey Kardashevskiy @ 2026-05-27 0:16 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-coco, iommu, linux-kernel, kvm
Cc: Bjorn Helgaas, Dan Williams, Jason Gunthorpe, Joerg Roedel,
Jonathan Cameron, Kevin Tian, Nicolin Chen, Samuel Ortiz,
Steven Price, Suzuki K Poulose, Will Deacon, Xu Yilun,
Shameer Kolothum, Paolo Bonzini, Tony Krowiak, Halil Pasic,
Jason Herne, Harald Freudenberger, Holger Dengler, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Alex Williamson, Matthew Rosato, Farhan Ali,
Eric Farman, linux-s390
In-Reply-To: <20260525154816.1029642-6-aneesh.kumar@kernel.org>
On 26/5/26 01:48, Aneesh Kumar K.V (Arm) wrote:
> Add IOMMU_VDEVICE_TSM_REQUEST for issuing TSM guest request/response
> transactions against an iommufd vdevice.
>
> The ioctl takes a vdevice_id plus request/response user buffers and length
> fields, and forwards the request through tsm_guest_req() to the PCI TSM
> backend. This provides the host-side passthrough path used by CoCo guests
> for TSM device attestation and acceptance flows after the device has been
> bound to TSM.
>
> Also add the supporting tsm_guest_req() helper and associated TSM core
> interface definitions.
>
> Based on changes from: Alexey Kardashevskiy <aik@amd.com>
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> drivers/iommu/iommufd/iommufd_private.h | 6 ++
> drivers/iommu/iommufd/main.c | 3 +
> drivers/iommu/iommufd/tsm.c | 68 +++++++++++++++++++++
> drivers/virt/coco/tsm-core.c | 39 ++++++++++++
> include/linux/pci-tsm.h | 9 +--
> include/linux/tsm.h | 25 ++++++++
> include/uapi/linux/iommufd.h | 80 +++++++++++++++++++++++++
> 7 files changed, 226 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
> index 8eea0c2c332b..0080895e9e92 100644
> --- a/drivers/iommu/iommufd/iommufd_private.h
> +++ b/drivers/iommu/iommufd/iommufd_private.h
> @@ -701,11 +701,17 @@ int iommufd_hw_queue_alloc_ioctl(struct iommufd_ucmd *ucmd);
> void iommufd_hw_queue_destroy(struct iommufd_object *obj);
> #ifdef CONFIG_TSM
> int iommufd_vdevice_tsm_op_ioctl(struct iommufd_ucmd *ucmd);
> +int iommufd_vdevice_tsm_req_ioctl(struct iommufd_ucmd *ucmd);
> #else
> static inline int iommufd_vdevice_tsm_op_ioctl(struct iommufd_ucmd *ucmd)
> {
> return -EOPNOTSUPP;
> }
> +
> +static inline int iommufd_vdevice_tsm_req_ioctl(struct iommufd_ucmd *ucmd)
> +{
> + return -EOPNOTSUPP;
> +}
> #endif
>
> static inline struct iommufd_vdevice *
> diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
> index d73e6b391c6f..5f49b546ec92 100644
> --- a/drivers/iommu/iommufd/main.c
> +++ b/drivers/iommu/iommufd/main.c
> @@ -433,6 +433,7 @@ union ucmd_buffer {
> struct iommu_vfio_ioas vfio_ioas;
> struct iommu_viommu_alloc viommu;
> struct iommu_vdevice_tsm_op tsm_op;
> + struct iommu_vdevice_tsm_req tsm_req;
> #ifdef CONFIG_IOMMUFD_TEST
> struct iommu_test_cmd test;
> #endif
> @@ -496,6 +497,8 @@ static const struct iommufd_ioctl_op iommufd_ioctl_ops[] = {
> struct iommu_viommu_alloc, out_viommu_id),
> IOCTL_OP(IOMMU_VDEVICE_TSM_OP, iommufd_vdevice_tsm_op_ioctl,
> struct iommu_vdevice_tsm_op, vdevice_id),
> + IOCTL_OP(IOMMU_VDEVICE_TSM_REQ, iommufd_vdevice_tsm_req_ioctl,
> + struct iommu_vdevice_tsm_req, resp_uptr),
> #ifdef CONFIG_IOMMUFD_TEST
> IOCTL_OP(IOMMU_TEST_CMD, iommufd_test, struct iommu_test_cmd, last),
> #endif
> diff --git a/drivers/iommu/iommufd/tsm.c b/drivers/iommu/iommufd/tsm.c
> index 09ee668dbed9..342fbdb6a6b9 100644
> --- a/drivers/iommu/iommufd/tsm.c
> +++ b/drivers/iommu/iommufd/tsm.c
> @@ -60,3 +60,71 @@ int iommufd_vdevice_tsm_op_ioctl(struct iommufd_ucmd *ucmd)
> iommufd_put_object(ucmd->ictx, &vdev->obj);
> return rc;
> }
> +
> +static bool iommufd_vdevice_tsm_req_scope_valid(u32 scope)
> +{
> + if (scope > IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_LAST)
> + return false;
> +
> + switch (scope) {
> + case IOMMU_VDEVICE_TSM_REQ_PCI_INFO:
> + case IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE:
> + case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ:
> + case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE:
This scope thing still needs clarification.
I have 3 types of requests to fit here, all go via VM -> KVM -> QEMU -> IOMMUFD -> TSM.
1) bind/unbind TDI <- moves to CONFIG_LOCKED, this is "OP";
2) start/stop TDI <- moves to RUN, this is "GR"? Right now I route it via "OP";
3) enable/disable MMIO/DMA <- no TDI state change, this is "GR" but which scope is it here?
thanks,
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +/**
> + * iommufd_vdevice_tsm_req_ioctl - Forward TSM requests
> + * @ucmd: user command data for IOMMU_VDEVICE_TSM_REQ
> + *
> + * Resolve @iommu_vdevice_tsm_req::vdevice_id to a vdevice and pass the
> + * request/response buffers to the TSM core.
> + *
> + * Return:
> + * -errno on error.
> + * positive residue if response/request bytes were left unconsumed.
> + * if response buffer is provided, residue indicates the number of bytes
> + * not used in response buffer
> + * if there is no response buffer, residue indicates the number of bytes
> + * not consumed in req buffer
> + * 0 otherwise.
> + */
> +int iommufd_vdevice_tsm_req_ioctl(struct iommufd_ucmd *ucmd)
> +{
> + int rc;
> + struct iommufd_vdevice *vdev;
> + struct iommu_vdevice_tsm_req *cmd = ucmd->cmd;
> + struct tsm_guest_req_info info = {
> + .scope = cmd->scope,
> + .req = {
> + .user = u64_to_user_ptr(cmd->req_uptr),
> + .is_kernel = false,
> + },
> + .req_len = cmd->req_len,
> + .resp = {
> + .user = u64_to_user_ptr(cmd->resp_uptr),
> + .is_kernel = false,
> + },
> + .resp_len = cmd->resp_len,
> + };
> +
> + if (cmd->__reserved)
> + return -EOPNOTSUPP;
> +
> + if (!iommufd_vdevice_tsm_req_scope_valid(cmd->scope))
> + return -EINVAL;
> +
> + vdev = iommufd_get_vdevice(ucmd->ictx, cmd->vdevice_id);
> + if (IS_ERR(vdev))
> + return PTR_ERR(vdev);
> +
> + rc = tsm_guest_req(vdev->idev->dev, &info);
> +
> + /* No inline response, hence we don't need to copy the response */
> + iommufd_put_object(ucmd->ictx, &vdev->obj);
> + return rc;
> +}
> diff --git a/drivers/virt/coco/tsm-core.c b/drivers/virt/coco/tsm-core.c
> index 3870d08ffe0d..c24886851f9e 100644
> --- a/drivers/virt/coco/tsm-core.c
> +++ b/drivers/virt/coco/tsm-core.c
> @@ -8,6 +8,7 @@
> #include <linux/module.h>
> #include <linux/cleanup.h>
> #include <linux/pci-tsm.h>
> +#include <uapi/linux/iommufd.h>
>
> static void tsm_release(struct device *);
> static const struct class tsm_class = {
> @@ -127,6 +128,44 @@ int tsm_unbind(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(tsm_unbind);
>
> +static int tsm_pci_req_scope(u32 scope, enum pci_tsm_req_scope *pci_scope)
> +{
> + switch (scope) {
> + case IOMMU_VDEVICE_TSM_REQ_PCI_INFO:
> + *pci_scope = PCI_TSM_REQ_INFO;
> + return 0;
> + case IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE:
> + *pci_scope = PCI_TSM_REQ_STATE_CHANGE;
> + return 0;
> + case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ:
> + *pci_scope = PCI_TSM_REQ_DEBUG_READ;
> + return 0;
> + case IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE:
> + *pci_scope = PCI_TSM_REQ_DEBUG_WRITE;
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +ssize_t tsm_guest_req(struct device *dev, struct tsm_guest_req_info *info)
> +{
> + int ret;
> + enum pci_tsm_req_scope pci_scope;
> +
> + if (!dev_is_pci(dev))
> + return -EINVAL;
> +
> + ret = tsm_pci_req_scope(info->scope, &pci_scope);
> + if (ret)
> + return ret;
> +
> + return pci_tsm_guest_req(to_pci_dev(dev), pci_scope, info->req,
> + info->req_len, info->resp, info->resp_len,
> + NULL);
> +}
> +EXPORT_SYMBOL_GPL(tsm_guest_req);
> +
> static void tsm_release(struct device *dev)
> {
> struct tsm_dev *tsm_dev = container_of(dev, typeof(*tsm_dev), dev);
> diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
> index a6435aba03f9..ec2236a7a279 100644
> --- a/include/linux/pci-tsm.h
> +++ b/include/linux/pci-tsm.h
> @@ -4,6 +4,7 @@
> #include <linux/mutex.h>
> #include <linux/pci.h>
> #include <linux/sockptr.h>
> +#include <uapi/linux/iommufd.h>
>
> struct pci_tsm;
> struct tsm_dev;
> @@ -173,7 +174,7 @@ enum pci_tsm_req_scope {
> * typical TDISP collateral information like Device Interface Reports.
> * No device secrets are permitted, and no device state is changed.
> */
> - PCI_TSM_REQ_INFO = 0,
> + PCI_TSM_REQ_INFO = IOMMU_VDEVICE_TSM_REQ_PCI_INFO,
> /**
> * @PCI_TSM_REQ_STATE_CHANGE: Request to change the TDISP state from
> * UNLOCKED->LOCKED, LOCKED->RUN, or other architecture specific state
> @@ -181,14 +182,14 @@ enum pci_tsm_req_scope {
> * to TDISP) device / host state, configuration, or data change is
> * permitted.
> */
> - PCI_TSM_REQ_STATE_CHANGE = 1,
> + PCI_TSM_REQ_STATE_CHANGE = IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE,
> /**
> * @PCI_TSM_REQ_DEBUG_READ: Read-only request for debug information
> *
> * A method to facilitate TVM information retrieval outside of typical
> * TDISP operational requirements. No device secrets are permitted.
> */
> - PCI_TSM_REQ_DEBUG_READ = 2,
> + PCI_TSM_REQ_DEBUG_READ = IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ,
> /**
> * @PCI_TSM_REQ_DEBUG_WRITE: Device state changes for debug purposes
> *
> @@ -196,7 +197,7 @@ enum pci_tsm_req_scope {
> * the TDISP operational model. If allowed, requires CAP_SYS_RAW_IO, and
> * will taint the kernel.
> */
> - PCI_TSM_REQ_DEBUG_WRITE = 3,
> + PCI_TSM_REQ_DEBUG_WRITE = IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE,
> };
>
> #ifdef CONFIG_PCI_TSM
> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> index 7b6df827321b..6101a2a1db61 100644
> --- a/include/linux/tsm.h
> +++ b/include/linux/tsm.h
> @@ -6,6 +6,7 @@
> #include <linux/types.h>
> #include <linux/uuid.h>
> #include <linux/device.h>
> +#include <linux/sockptr.h>
>
> #define TSM_REPORT_INBLOB_MAX 64
> #define TSM_REPORT_OUTBLOB_MAX SZ_16M
> @@ -128,6 +129,23 @@ struct kvm;
> #ifdef CONFIG_TSM
> int tsm_bind(struct device *dev, struct kvm *kvm, u64 tdi_id);
> int tsm_unbind(struct device *dev);
> +
> +/**
> + * struct tsm_guest_req_info - parameter for tsm_guest_req()
> + * @scope: iommufd allocated scope for tsm guest request
> + * @req: request data buffer filled by guest
> + * @req_len: the size of @req filled by guest
> + * @resp: response data buffer filled by host
> + * @resp_len: the size of @resp buffer filled by guest
> + */
> +struct tsm_guest_req_info {
> + u32 scope;
> + sockptr_t req;
> + size_t req_len;
> + sockptr_t resp;
> + size_t resp_len;
> +};
> +ssize_t tsm_guest_req(struct device *dev, struct tsm_guest_req_info *info);
> #else
> static inline int tsm_bind(struct device *dev, struct kvm *kvm, u64 tdi_id)
> {
> @@ -138,6 +156,13 @@ static inline int tsm_unbind(struct device *dev)
> {
> return 0;
> }
> +
> +struct tsm_guest_req_info;
> +static inline ssize_t tsm_guest_req(struct device *dev,
> + struct tsm_guest_req_info *info)
> +{
> + return -EINVAL;
> +}
> #endif
>
> #endif /* __TSM_H */
> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
> index 66398efa31d1..7953e99a9671 100644
> --- a/include/uapi/linux/iommufd.h
> +++ b/include/uapi/linux/iommufd.h
> @@ -58,6 +58,7 @@ enum {
> IOMMUFD_CMD_VEVENTQ_ALLOC = 0x93,
> IOMMUFD_CMD_HW_QUEUE_ALLOC = 0x94,
> IOMMUFD_CMD_VDEVICE_TSM_OP = 0x95,
> + IOMMUFD_CMD_VDEVICE_TSM_REQ = 0x96,
> };
>
> /**
> @@ -1373,4 +1374,83 @@ struct iommu_hw_queue_alloc {
> __aligned_u64 length;
> };
> #define IOMMU_HW_QUEUE_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HW_QUEUE_ALLOC)
> +
> +/*
> + * TSM request scope values are allocated by iommufd. Each device-bus transport
> + * gets a range from this number space.
> + */
> +#define IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_BASE 0
> +
> +enum iommu_vdevice_tsm_req_scope {
> + /*
> + * Read-only, without side effects, request for typical TDISP
> + * collateral information like Device Interface Reports. No device
> + * secrets are permitted, and no device state is changed.
> + */
> + IOMMU_VDEVICE_TSM_REQ_PCI_INFO =
> + IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_BASE,
> + /*
> + * Request to change the TDISP state from UNLOCKED->LOCKED,
> + * LOCKED->RUN, or other architecture specific state changes to
> + * support those transitions for a TDI. No other device or host state,
> + * configuration, or data change is permitted.
> + */
> + IOMMU_VDEVICE_TSM_REQ_PCI_STATE_CHANGE =
> + IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_BASE + 1,
> + /*
> + * Read-only request for debug information outside of typical TDISP
> + * operational requirements. No device secrets are permitted.
> + */
> + IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_READ =
> + IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_BASE + 2,
> + /*
> + * Device state changes for debug purposes. The request may affect the
> + * operational state of the device outside of the TDISP operational
> + * model. If allowed, this requires CAP_SYS_RAW_IO and taints the
> + * kernel.
> + */
> + IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE =
> + IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_BASE + 3,
> + IOMMU_VDEVICE_TSM_REQ_SCOPE_PCI_LAST =
> + IOMMU_VDEVICE_TSM_REQ_PCI_DEBUG_WRITE,
> +};
> +
> +/**
> + * struct iommu_vdevice_tsm_req - ioctl(IOMMU_VDEVICE_TSM_REQ)
> + * @size: sizeof(struct iommu_vdevice_tsm_req)
> + * @vdevice_id: vDevice ID the guest request is for
> + * @scope: One of enum iommu_vdevice_tsm_req_scope
> + * @req_len: Size in bytes of the input payload at @req_uptr
> + * @resp_len: Size in bytes of the output buffer at @resp_uptr
> + * @__reserved: Must be 0
> + * @req_uptr: Userspace pointer to the guest-provided request payload
> + * @resp_uptr: Userspace pointer to the guest response buffer
> + *
> + * Forward a TSM request to the TSM bound vDevice. This is intended for
> + * guest TSM/TDISP message transport where the host kernel only marshals
> + * bytes between userspace and the TSM implementation.
> + *
> + * Requests outside the iommufd allocated scope values are rejected. Lower
> + * layers may reject scope values that are valid in the global iommufd
> + * namespace, but not permitted for a specific bus.
> + *
> + * The request payload is read from @req_uptr/@req_len. If a response is
> + * expected, userspace provides @resp_uptr/@resp_len as writable storage for
> + * response bytes returned by the TSM path.
> + *
> + * The ioctl is only suitable for commands and results that the host kernel
> + * has no use, the host is only facilitating guest to TSM communication.
> + */
> +struct iommu_vdevice_tsm_req {
> + __u32 size;
> + __u32 vdevice_id;
> + __u32 scope;
> + __u32 req_len;
> + __u32 resp_len;
> + __u32 __reserved;
> + __aligned_u64 req_uptr;
> + __aligned_u64 resp_uptr;
> +};
> +
> +#define IOMMU_VDEVICE_TSM_REQ _IO(IOMMUFD_TYPE, IOMMUFD_CMD_VDEVICE_TSM_REQ)
> #endif
--
Alexey
^ permalink raw reply
* Re: [RFC PATCH 15/15] x86/virt/tdx: Enable TDX Quoting extension
From: Xiaoyao Li @ 2026-05-27 1:30 UTC (permalink / raw)
To: Xu Yilun
Cc: Tony Lindgren, kas, djbw, rick.p.edgecombe, x86, peter.fang,
linux-coco, linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan
In-Reply-To: <ahXAL41ZmIDHmgfu@yilunxu-OptiPlex-7050>
On 5/26/2026 11:45 PM, Xu Yilun wrote:
> On Mon, May 25, 2026 at 06:51:27PM +0800, Xiaoyao Li wrote:
>> On 5/25/2026 1:17 PM, Tony Lindgren wrote:
>>> On Fri, May 22, 2026 at 11:41:28AM +0800, Xu Yilun wrote:
>>>> From: Peter Fang <peter.fang@intel.com>
>>>>
>>>> TDX Module updates global metadata when add-on features are enabled.
>>>> Host should update the cached tdx_sysinfo to reflect these changes.
>>>
>>> This should be made clearer IMO. How about mention that get_tdx_sys_info()
>>> needs to get called again to reload the TDX module global metadata?
>>
>> Ah ha! This patch answers my comment to patch 1:
>> https://lore.kernel.org/all/956fa1e6-2920-4b2e-8037-d4b9d812ae53@intel.com/
>>
>> sysinfo_ext->memory_pool_required_pages and sysinfo_ext->ext_required will
>> be updated after extensions are enabled by TDH.SYS.CONFIG.
>>
>> Patch 06 in this series already reads the tdx_sys_info_quote out of
>> get_tdx_sys_info(), which mean get_tdx_sys_info() doesn't ensure all the
>> global metadata will be update again.
>>
>> So how about move the read of memory_pool_required_pages and ext_required
>> out of get_tdx_sys_info() and put them after TDH.SYS.CONFIG, so that we
>> don't need call get_tdx_sys_info() again?
>
> Yes, I'm good to it. I hesitated to move them out in case we need some
> central control on global data. But now I see there is already a
> precedent:
>
> https://lore.kernel.org/kvm/20260520133909.409394-22-chao.gao@intel.com/
>
> Once we've agreed on moving add-on data reading out of get_tdx_sys_info(),
> we don't have to read them after TDH.SYS.CONFIG, read them when really
> needed. How about the following, that makes the Extension part in this
> series self-contained.
Actually below is what I meant after TDH.SYS.CONFIG.
And I think we can re-order the patches of enabling TDX extensions by
moving the patch 04 as the first one.
> ----8<----
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 86e5b7ad19b3..b729c1f5ab9e 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1536,6 +1536,10 @@ static __init int init_tdx_ext(void)
> if (!(tdx_sysinfo.features.tdx_features0 & TDX_FEATURES0_EXT))
> return 0;
>
> + ret = get_tdx_sys_info_ext(&tdx_sysinfo.ext);
> + if (ret)
> + return ret;
> +
> /* No feature requires TDX Module Extensions. */
> if (!tdx_sysinfo.ext.ext_required)
> return 0;
> diff --git a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> index f9cc2dd02caf..e7d9e0c4b604 100644
> --- a/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> +++ b/arch/x86/virt/vmx/tdx/tdx_global_metadata.c
> @@ -140,8 +140,5 @@ static __init int get_tdx_sys_info(struct tdx_sys_info *sysinfo)
> ret = ret ?: get_tdx_sys_info_td_ctrl(&sysinfo->td_ctrl);
> ret = ret ?: get_tdx_sys_info_td_conf(&sysinfo->td_conf);
>
> - if (sysinfo->features.tdx_features0 & TDX_FEATURES0_EXT)
> - ret = ret ?: get_tdx_sys_info_ext(&sysinfo->ext);
> -
> return ret;
> }
^ permalink raw reply
* Re: [PATCH 02/15] x86/virt/tdx: Add extra memory to TDX Module for Extensions
From: Xu Yilun @ 2026-05-27 3:47 UTC (permalink / raw)
To: Xiaoyao Li
Cc: kas, djbw, rick.p.edgecombe, x86, peter.fang, linux-coco,
linux-kernel, kvm, sohil.mehta, yilun.xu, baolu.lu,
zhenzhong.duan
In-Reply-To: <7139c55b-b949-415d-ab82-fca1b1cc3880@intel.com>
> > +static void tdx_clflush_hpa_list(struct page *root, unsigned int nr_pages)
> > +{
> > + u64 *entries = page_to_virt(root);
> > + int i;
> > +
> > + for (i = 0; i < nr_pages; i++)
> > + clflush_cache_range(__va(entries[i]), PAGE_SIZE);
>
> Is the page flush only needed when CLFLUSH_BEFORE_ALLOC is true?
>
> If so, it inherits the same decision to always flush as what
Yes it is basically the same as tdx_clflush_page().
> tdx_clflush_page() did. Then, any chance we can use tdx_clflush_page() here
But I don't think we should convert hpa/page/va back and forth just for
re-using one line of code.
> so that we have a single central place of the comment to explain the kernel
> design decision.
How about I add a comment here to connect this wrapper to
tdx_clflush_page():
/*
* Unconditionally flush the pages regardless of CLFLUSH_BEFORE_ALLOC. Inherit
* the same decision as tdx_clflush_page().
*/
static void tdx_clflush_hpa_list(struct page *root, unsigned int nr_pages)
...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox