* [PATCH v2 4/4] dma: direct: set decrypted flag for remapped dma allocations
From: Aneesh Kumar K.V (Arm) @ 2025-12-21 16:09 UTC (permalink / raw)
To: linux-kernel, iommu, linux-coco
Cc: Catalin Marinas, will, maz, tglx, robin.murphy, suzuki.poulose,
akpm, jgg, steven.price, Aneesh Kumar K.V (Arm)
In-Reply-To: <20251221160920.297689-1-aneesh.kumar@kernel.org>
Devices that are DMA non-coherent and need a remap were skipping
dma_set_decrypted(), leaving buffers encrypted even when the device
requires unencrypted access. Move the call after the remap
branch so both paths mark the allocation decrypted (or fail cleanly)
before use.
Fixes: f3c962226dbe ("dma-direct: clean up the remapping checks in dma_direct_alloc")
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3448d877c7c6..a62dc25524cc 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -271,9 +271,6 @@ void *dma_direct_alloc(struct device *dev, size_t size,
if (remap) {
pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
- if (force_dma_unencrypted(dev))
- prot = pgprot_decrypted(prot);
-
/* remove any dirty cache lines on the kernel alias */
arch_dma_prep_coherent(page, size);
@@ -284,10 +281,11 @@ void *dma_direct_alloc(struct device *dev, size_t size,
goto out_free_pages;
} else {
ret = page_address(page);
- if (dma_set_decrypted(dev, ret, size))
- goto out_leak_pages;
}
+ if (dma_set_decrypted(dev, ret, size))
+ goto out_leak_pages;
+
memset(ret, 0, size);
if (set_uncached) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] coco: host: arm64: Handle hostconf RHI calls in kernel
From: Aneesh Kumar K.V (Arm) @ 2025-12-21 16:09 UTC (permalink / raw)
To: linux-kernel, iommu, linux-coco
Cc: Catalin Marinas, will, maz, tglx, robin.murphy, suzuki.poulose,
akpm, jgg, steven.price, Aneesh Kumar K.V (Arm)
In-Reply-To: <20251221160920.297689-1-aneesh.kumar@kernel.org>
- Mark hostconf RHI SMC IDs as handled in the SMCCC filter.
- Return version/features plus PAGE_SIZE alignment for guest queries.
- Drop the 4K page-size guard in RMI init now that realm can query IPA
change alignment size via the hostconf RHI
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
arch/arm64/kvm/hypercalls.c | 23 ++++++++++++++++++++++-
arch/arm64/kvm/rmi.c | 4 ----
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 70ac7971416c..2861ca9063dd 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -8,6 +8,7 @@
#include <kvm/arm_hypercalls.h>
#include <kvm/arm_psci.h>
+#include <asm/rhi.h>
#define KVM_ARM_SMCCC_STD_FEATURES \
GENMASK(KVM_REG_ARM_STD_BMAP_BIT_COUNT - 1, 0)
@@ -77,6 +78,9 @@ static bool kvm_smccc_default_allowed(u32 func_id)
*/
case ARM_SMCCC_VERSION_FUNC_ID:
case ARM_SMCCC_ARCH_FEATURES_FUNC_ID:
+ case RHI_HOSTCONF_VERSION:
+ case RHI_HOSTCONF_FEATURES:
+ case RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT:
return true;
default:
/* PSCI 0.2 and up is in the 0:0x1f range */
@@ -157,7 +161,15 @@ static int kvm_smccc_filter_insert_reserved(struct kvm *kvm)
GFP_KERNEL_ACCOUNT);
if (r)
goto out_destroy;
-
+ /*
+ * Don't forward RHI_HOST_CONF related RHI calls
+ */
+ r = mtree_insert_range(&kvm->arch.smccc_filter,
+ RHI_HOSTCONF_VERSION, RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT,
+ xa_mk_value(KVM_SMCCC_FILTER_HANDLE),
+ GFP_KERNEL_ACCOUNT);
+ if (r)
+ goto out_destroy;
return 0;
out_destroy:
mtree_destroy(&kvm->arch.smccc_filter);
@@ -376,6 +388,15 @@ int kvm_smccc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_TRNG_RND32:
case ARM_SMCCC_TRNG_RND64:
return kvm_trng_call(vcpu);
+ case RHI_HOSTCONF_VERSION:
+ val[0] = RHI_HOSTCONF_VER_1_0;
+ break;
+ case RHI_HOSTCONF_FEATURES:
+ val[0] = __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
+ break;
+ case RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT:
+ val[0] = PAGE_SIZE;
+ break;
default:
return kvm_psci_call(vcpu);
}
diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
index 9957a71d21b1..bd345e051a24 100644
--- a/arch/arm64/kvm/rmi.c
+++ b/arch/arm64/kvm/rmi.c
@@ -1935,10 +1935,6 @@ EXPORT_SYMBOL_GPL(kvm_has_da_feature);
void kvm_init_rmi(void)
{
- /* Only 4k page size on the host is supported */
- if (PAGE_SIZE != SZ_4K)
- return;
-
/* Continue without realm support if we can't agree on a version */
if (rmi_check_version())
return;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] coco: guest: arm64: Fetch host IPA change alignment via RHI hostconf
From: Aneesh Kumar K.V (Arm) @ 2025-12-21 16:09 UTC (permalink / raw)
To: linux-kernel, iommu, linux-coco
Cc: Catalin Marinas, will, maz, tglx, robin.murphy, suzuki.poulose,
akpm, jgg, steven.price, Aneesh Kumar K.V (Arm)
In-Reply-To: <20251221160920.297689-1-aneesh.kumar@kernel.org>
- add RHI hostconf SMC IDs and helper to query version, features, and IPA change alignment
- derive the realm hypervisor page size during init and abort realm setup on invalid alignment
- make `mem_encrypt_align()` realign to the host page size for realm guests and export the helper
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
arch/arm64/include/asm/mem_encrypt.h | 5 +--
arch/arm64/include/asm/rhi.h | 7 ++++
arch/arm64/include/asm/rsi.h | 1 +
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/rhi.c | 54 ++++++++++++++++++++++++++++
arch/arm64/kernel/rsi.c | 13 +++++++
arch/arm64/mm/mem_encrypt.c | 8 +++++
7 files changed, 85 insertions(+), 5 deletions(-)
create mode 100644 arch/arm64/kernel/rhi.c
diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
index b7ac143b81ce..06d3c30159a2 100644
--- a/arch/arm64/include/asm/mem_encrypt.h
+++ b/arch/arm64/include/asm/mem_encrypt.h
@@ -18,10 +18,7 @@ int set_memory_decrypted(unsigned long addr, int numpages);
bool force_dma_unencrypted(struct device *dev);
#define mem_encrypt_align mem_encrypt_align
-static inline size_t mem_encrypt_align(size_t size)
-{
- return size;
-}
+size_t mem_encrypt_align(size_t size);
int realm_register_memory_enc_ops(void);
diff --git a/arch/arm64/include/asm/rhi.h b/arch/arm64/include/asm/rhi.h
index a4f56f536876..414d9eab7f65 100644
--- a/arch/arm64/include/asm/rhi.h
+++ b/arch/arm64/include/asm/rhi.h
@@ -86,4 +86,11 @@ enum rhi_tdi_state {
#define __REC_EXIT_DA_VDEV_MAP 0x6
#define __RHI_DA_VDEV_SET_TDI_STATE 0x7
+unsigned long rhi_get_ipa_change_alignment(void);
+#define RHI_HOSTCONF_VER_1_0 0x10000
+#define RHI_HOSTCONF_VERSION SMC_RHI_CALL(0x004E)
+
+#define __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT BIT(0)
+#define RHI_HOSTCONF_FEATURES SMC_RHI_CALL(0x004F)
+#define RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT SMC_RHI_CALL(0x0050)
#endif
diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
index c197bcc50239..2781d89827eb 100644
--- a/arch/arm64/include/asm/rsi.h
+++ b/arch/arm64/include/asm/rsi.h
@@ -79,5 +79,6 @@ static inline int rsi_set_memory_range_shared(phys_addr_t start,
}
bool rsi_has_da_feature(void);
+unsigned long realm_get_hyp_pagesize(void);
#endif /* __ASM_RSI_H_ */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 76f32e424065..fcb67f50ea89 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -34,7 +34,7 @@ obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
cpufeature.o alternative.o cacheinfo.o \
smp.o smp_spin_table.o topology.o smccc-call.o \
syscall.o proton-pack.o idle.o patching.o pi/ \
- rsi.o jump_label.o
+ rsi.o jump_label.o rhi.o
obj-$(CONFIG_COMPAT) += sys32.o signal32.o \
sys_compat.o
diff --git a/arch/arm64/kernel/rhi.c b/arch/arm64/kernel/rhi.c
new file mode 100644
index 000000000000..63360ed392e4
--- /dev/null
+++ b/arch/arm64/kernel/rhi.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 ARM Ltd.
+ */
+
+#include <asm/rsi.h>
+#include <asm/rhi.h>
+
+/* we need an aligned rhicall for rsi_host_call. slab is not yet ready */
+static struct rsi_host_call hyp_pagesize_rhicall;
+unsigned long rhi_get_ipa_change_alignment(void)
+{
+ long ret;
+ unsigned long ipa_change_align;
+
+ hyp_pagesize_rhicall.imm = 0;
+ hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_VERSION;
+ ret = rsi_host_call(&hyp_pagesize_rhicall);
+ if (ret != RSI_SUCCESS)
+ goto err_out;
+
+ if (hyp_pagesize_rhicall.gprs[0] != RHI_HOSTCONF_VER_1_0)
+ goto err_out;
+
+ hyp_pagesize_rhicall.imm = 0;
+ hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_FEATURES;
+ ret = rsi_host_call(&hyp_pagesize_rhicall);
+ if (ret != RSI_SUCCESS)
+ goto err_out;
+
+ if (!(hyp_pagesize_rhicall.gprs[0] & __RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT))
+ goto err_out;
+
+ hyp_pagesize_rhicall.imm = 0;
+ hyp_pagesize_rhicall.gprs[0] = RHI_HOSTCONF_GET_IPA_CHANGE_ALIGNMENT;
+ ret = rsi_host_call(&hyp_pagesize_rhicall);
+ if (ret != RSI_SUCCESS)
+ goto err_out;
+
+ ipa_change_align = hyp_pagesize_rhicall.gprs[0];
+ /* This error needs special handling in the caller */
+ if (ipa_change_align & (SZ_4K - 1))
+ return 0;
+
+ return ipa_change_align;
+
+err_out:
+ /*
+ * For failure condition assume host is built with 4K page size
+ * and hence ipa change alignment can be guest PAGE_SIZE.
+ */
+ return PAGE_SIZE;
+}
+
diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index aae24009cadb..57de4103be03 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -13,9 +13,12 @@
#include <asm/io.h>
#include <asm/mem_encrypt.h>
#include <asm/rsi.h>
+#include <asm/rhi.h>
static struct realm_config config;
static u64 rsi_feat_reg0;
+static unsigned long ipa_change_alignment = PAGE_SIZE;
+
unsigned long prot_ns_shared;
EXPORT_SYMBOL(prot_ns_shared);
@@ -147,6 +150,11 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
return 0;
}
+unsigned long realm_get_hyp_pagesize(void)
+{
+ return ipa_change_alignment;
+}
+
void __init arm64_rsi_init(void)
{
static_branch_enable(&rsi_init_call_done);
@@ -158,6 +166,11 @@ void __init arm64_rsi_init(void)
if (WARN_ON(rsi_get_realm_config(&config)))
return;
+ ipa_change_alignment = rhi_get_ipa_change_alignment();
+ /* If we don't get a correct alignment response, don't enable realm */
+ if (!ipa_change_alignment)
+ return;
+
if (WARN_ON(rsi_features(0, &rsi_feat_reg0)))
return;
diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
index deb364eadd47..6937f753e89d 100644
--- a/arch/arm64/mm/mem_encrypt.c
+++ b/arch/arm64/mm/mem_encrypt.c
@@ -64,3 +64,11 @@ bool force_dma_unencrypted(struct device *dev)
return is_realm_world();
}
EXPORT_SYMBOL_GPL(force_dma_unencrypted);
+
+size_t mem_encrypt_align(size_t size)
+{
+ if (is_realm_world())
+ return ALIGN(size, realm_get_hyp_pagesize());
+ return size;
+}
+EXPORT_SYMBOL_GPL(mem_encrypt_align);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] swiotlb: dma: its: Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V (Arm) @ 2025-12-21 16:09 UTC (permalink / raw)
To: linux-kernel, iommu, linux-coco
Cc: Catalin Marinas, will, maz, tglx, robin.murphy, suzuki.poulose,
akpm, jgg, steven.price, Aneesh Kumar K.V (Arm)
In-Reply-To: <20251221160920.297689-1-aneesh.kumar@kernel.org>
When running private-memory guests, the guest kernel must apply
additional constraints when allocating buffers that are shared with the
hypervisor.
These shared buffers are also accessed by the host kernel and therefore
must be aligned to the host’s page size.
On non-secure hosts, set_guest_memory_attributes() tracks memory at the
host PAGE_SIZE granularity. This creates a mismatch when the guest
applies attributes at 4K boundaries while the host uses 64K pages. In
such cases, the call returns -EINVAL, preventing the conversion of
memory regions from private to shared.
Architectures such as Arm can tolerate realm physical address space PFNs
being mapped as shared memory, as incorrect accesses are detected and
reported as GPC faults. However, relying on this mechanism is unsafe and
can still lead to kernel crashes.
This is particularly likely when guest_memfd allocations are mmapped and
accessed from userspace. Once exposed to userspace, we cannot guarantee
that applications will only access the intended 4K shared region rather
than the full 64K page mapped into their address space. Such userspace
addresses may also be passed back into the kernel and accessed via the
linear map, resulting in a GPC fault and a kernel crash.
With CCA, although Stage-2 mappings managed by the RMM still operate at
a 4K granularity, shared pages must nonetheless be aligned to the
host-managed page size to avoid the issues described above.
Introduce a new helper, mem_encryp_align(), to allow callers to enforce
the required alignment for shared buffers.
The architecture-specific implementation of mem_encrypt_align() will be
provided in a follow-up patch.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
arch/arm64/include/asm/mem_encrypt.h | 6 ++++++
arch/arm64/mm/mem_encrypt.c | 6 ++++++
drivers/irqchip/irq-gic-v3-its.c | 7 ++++---
include/linux/mem_encrypt.h | 7 +++++++
kernel/dma/contiguous.c | 10 ++++++++++
kernel/dma/direct.c | 6 ++++++
kernel/dma/pool.c | 6 ++++--
kernel/dma/swiotlb.c | 18 ++++++++++++------
8 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
index d77c10cd5b79..b7ac143b81ce 100644
--- a/arch/arm64/include/asm/mem_encrypt.h
+++ b/arch/arm64/include/asm/mem_encrypt.h
@@ -17,6 +17,12 @@ int set_memory_encrypted(unsigned long addr, int numpages);
int set_memory_decrypted(unsigned long addr, int numpages);
bool force_dma_unencrypted(struct device *dev);
+#define mem_encrypt_align mem_encrypt_align
+static inline size_t mem_encrypt_align(size_t size)
+{
+ return size;
+}
+
int realm_register_memory_enc_ops(void);
/*
diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
index 645c099fd551..deb364eadd47 100644
--- a/arch/arm64/mm/mem_encrypt.c
+++ b/arch/arm64/mm/mem_encrypt.c
@@ -46,6 +46,12 @@ int set_memory_decrypted(unsigned long addr, int numpages)
if (likely(!crypt_ops) || WARN_ON(!PAGE_ALIGNED(addr)))
return 0;
+ if (WARN_ON(!IS_ALIGNED(addr, mem_encrypt_align(PAGE_SIZE))))
+ return 0;
+
+ if (WARN_ON(!IS_ALIGNED(numpages << PAGE_SHIFT, mem_encrypt_align(PAGE_SIZE))))
+ return 0;
+
return crypt_ops->decrypt(addr, numpages);
}
EXPORT_SYMBOL_GPL(set_memory_decrypted);
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 467cb78435a9..ffb8ef3a1eb3 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -213,16 +213,17 @@ static gfp_t gfp_flags_quirk;
static struct page *its_alloc_pages_node(int node, gfp_t gfp,
unsigned int order)
{
+ unsigned int new_order;
struct page *page;
int ret = 0;
- page = alloc_pages_node(node, gfp | gfp_flags_quirk, order);
-
+ new_order = get_order(mem_encrypt_align((PAGE_SIZE << order)));
+ page = alloc_pages_node(node, gfp | gfp_flags_quirk, new_order);
if (!page)
return NULL;
ret = set_memory_decrypted((unsigned long)page_address(page),
- 1 << order);
+ 1 << new_order);
/*
* If set_memory_decrypted() fails then we don't know what state the
* page is in, so we can't free it. Instead we leak it.
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index 07584c5e36fb..a0b9f6fe5d1a 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -54,6 +54,13 @@
#define dma_addr_canonical(x) (x)
#endif
+#ifndef mem_encrypt_align
+static inline size_t mem_encrypt_align(size_t size)
+{
+ return size;
+}
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* __MEM_ENCRYPT_H__ */
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index d9b9dcba6ff7..35f738c9eee2 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -45,6 +45,7 @@
#include <linux/dma-map-ops.h>
#include <linux/cma.h>
#include <linux/nospec.h>
+#include <linux/dma-direct.h>
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -356,6 +357,15 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
int nid = dev_to_node(dev);
#endif
+ /*
+ * for untrusted device, we require the dma buffers to be aligned to
+ * the size of allocation. if we can't do that with cma allocation, fail
+ * cma allocation early.
+ */
+ if (force_dma_unencrypted(dev))
+ if (get_order(size) > CONFIG_CMA_ALIGNMENT)
+ return NULL;
+
/* CMA can be used only in the context which permits sleeping */
if (!gfpflags_allow_blocking(gfp))
return NULL;
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 1f9ee9759426..3448d877c7c6 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -250,6 +250,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ if (force_dma_unencrypted(dev))
+ size = mem_encrypt_align(size);
+
/* we always manually zero the memory once we are done */
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
if (!page)
@@ -359,6 +362,9 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ if (force_dma_unencrypted(dev))
+ size = mem_encrypt_align(size);
+
page = __dma_direct_alloc_pages(dev, size, gfp, false);
if (!page)
return NULL;
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index ee45dee33d49..86615e088240 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -80,12 +80,13 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
gfp_t gfp)
{
unsigned int order;
+ unsigned int min_encrypt_order = get_order(mem_encrypt_align(PAGE_SIZE));
struct page *page = NULL;
void *addr;
int ret = -ENOMEM;
/* Cannot allocate larger than MAX_PAGE_ORDER */
- order = min(get_order(pool_size), MAX_PAGE_ORDER);
+ order = min(get_order(mem_encrypt_align(pool_size)), MAX_PAGE_ORDER);
do {
pool_size = 1 << (PAGE_SHIFT + order);
@@ -94,7 +95,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
order, false);
if (!page)
page = alloc_pages(gfp, order);
- } while (!page && order-- > 0);
+ } while (!page && order-- > min_encrypt_order);
if (!page)
goto out;
@@ -196,6 +197,7 @@ static int __init dma_atomic_pool_init(void)
unsigned long pages = totalram_pages() / (SZ_1G / SZ_128K);
pages = min_t(unsigned long, pages, MAX_ORDER_NR_PAGES);
atomic_pool_size = max_t(size_t, pages << PAGE_SHIFT, SZ_128K);
+ WARN_ON(!IS_ALIGNED(atomic_pool_size, mem_encrypt_align(PAGE_SIZE)));
}
INIT_WORK(&atomic_pool_work, atomic_pool_work_fn);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 0d37da3d95b6..db53dc7bff6a 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -319,8 +319,8 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
unsigned int flags,
int (*remap)(void *tlb, unsigned long nslabs))
{
- size_t bytes = PAGE_ALIGN(nslabs << IO_TLB_SHIFT);
void *tlb;
+ size_t bytes = mem_encrypt_align(nslabs << IO_TLB_SHIFT);
/*
* By default allocate the bounce buffer memory from low memory, but
@@ -328,9 +328,9 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
* memory encryption.
*/
if (flags & SWIOTLB_ANY)
- tlb = memblock_alloc(bytes, PAGE_SIZE);
+ tlb = memblock_alloc(bytes, mem_encrypt_align(PAGE_SIZE));
else
- tlb = memblock_alloc_low(bytes, PAGE_SIZE);
+ tlb = memblock_alloc_low(bytes, mem_encrypt_align(PAGE_SIZE));
if (!tlb) {
pr_warn("%s: Failed to allocate %zu bytes tlb structure\n",
@@ -339,7 +339,7 @@ static void __init *swiotlb_memblock_alloc(unsigned long nslabs,
}
if (remap && remap(tlb, nslabs) < 0) {
- memblock_free(tlb, PAGE_ALIGN(bytes));
+ memblock_free(tlb, bytes);
pr_warn("%s: Failed to remap %zu bytes\n", __func__, bytes);
return NULL;
}
@@ -461,15 +461,21 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
swiotlb_adjust_nareas(num_possible_cpus());
retry:
- order = get_order(nslabs << IO_TLB_SHIFT);
+ order = get_order(mem_encrypt_align(nslabs << IO_TLB_SHIFT));
nslabs = SLABS_PER_PAGE << order;
+ WARN_ON(!IS_ALIGNED(order << PAGE_SHIFT, mem_encrypt_align(PAGE_SIZE)));
+ WARN_ON(!IS_ALIGNED(default_nslabs << IO_TLB_SHIFT, mem_encrypt_align(PAGE_SIZE)));
+ WARN_ON(!IS_ALIGNED(IO_TLB_MIN_SLABS << IO_TLB_SHIFT, mem_encrypt_align(PAGE_SIZE)));
+
while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
vstart = (void *)__get_free_pages(gfp_mask | __GFP_NOWARN,
order);
if (vstart)
break;
order--;
+ if (order < get_order(mem_encrypt_align(PAGE_SIZE)))
+ break;
nslabs = SLABS_PER_PAGE << order;
retried = true;
}
@@ -573,7 +579,7 @@ void __init swiotlb_exit(void)
*/
static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes, u64 phys_limit)
{
- unsigned int order = get_order(bytes);
+ unsigned int order = get_order(mem_encrypt_align(bytes));
struct page *page;
phys_addr_t paddr;
void *vaddr;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] Enforce host page-size alignment for shared buffers
From: Aneesh Kumar K.V (Arm) @ 2025-12-21 16:09 UTC (permalink / raw)
To: linux-kernel, iommu, linux-coco
Cc: Catalin Marinas, will, maz, tglx, robin.murphy, suzuki.poulose,
akpm, jgg, steven.price, Aneesh Kumar K.V (Arm)
Hi all,
This patch series addresses alignment requirements for buffers shared between
private-memory guests and the host.
When running private-memory guests, the guest kernel must apply additional
constraints when allocating buffers that are shared with the hypervisor. These
shared buffers are also accessed by the host kernel and therefore must be
aligned to the host’s page size.
Architectures such as Arm can tolerate realm physical address space PFNs being
mapped as shared memory, as incorrect accesses are detected and reported as GPC
faults. However, relying on this mechanism alone is unsafe and can still lead to
kernel crashes.
This is particularly likely when guest_memfd allocations are mmapped and
accessed from userspace. Once exposed to userspace, it is not possible to
guarantee that applications will only access the intended 4K shared region
rather than the full 64K page mapped into their address space. Such userspace
addresses may also be passed back into the kernel and accessed via the linear
map, potentially resulting in a GPC fault and a kernel crash.
To address this, the series introduces a new helper, `mem_encrypt_align()`,
which allows callers to enforce the required alignment for shared buffers.
The series is based on:
https://gitlab.arm.com/linux-arm/linux-cca.git cca/topics/cca-tdisp-integration-v2
It includes both arm64 guest and host changes to demonstrate a sample
implementation of `mem_encrypt_align()`, with the goal of making the intent and
usage clear for review.
I also included a fix for direct dma remapped coherent allocations related
memory encryption becuse it is also touching the same area. Based on feedback
here I will split that as a separate patch and can send that out
The series also includes a fix for direct DMA remapped allocations related to
memory encryption, as it touches the same code paths. Based on feedback, I can
split this fix into a separate patch and send it out independently.
Feedback and suggestions are welcome.
Changes from v1:
* Rename the helper to mem_encrypt_align
* Improve the commit message
* Handle DMA allocations from contiguous memory
* Handle DMA allocations from the pool
* swiotlb is still considered unencrypted. Support for an encrypted swiotlb pool
is left as TODO and is independent of this series.
Aneesh Kumar K.V (Arm) (4):
swiotlb: dma: its: Enforce host page-size alignment for shared buffers
coco: guest: arm64: Fetch host IPA change alignment via RHI hostconf
coco: host: arm64: Handle hostconf RHI calls in kernel
dma: direct: set decrypted flag for remapped coherent allocations
arch/arm64/include/asm/mem_encrypt.h | 3 ++
arch/arm64/include/asm/rhi.h | 7 ++++
arch/arm64/include/asm/rsi.h | 1 +
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/rhi.c | 54 ++++++++++++++++++++++++++++
arch/arm64/kernel/rsi.c | 13 +++++++
arch/arm64/kvm/hypercalls.c | 23 +++++++++++-
arch/arm64/kvm/rmi.c | 4 ---
arch/arm64/mm/mem_encrypt.c | 14 ++++++++
drivers/irqchip/irq-gic-v3-its.c | 7 ++--
include/linux/mem_encrypt.h | 7 ++++
kernel/dma/contiguous.c | 10 ++++++
kernel/dma/direct.c | 14 +++++---
kernel/dma/pool.c | 6 ++--
kernel/dma/swiotlb.c | 18 ++++++----
15 files changed, 161 insertions(+), 22 deletions(-)
create mode 100644 arch/arm64/kernel/rhi.c
--
2.43.0
^ permalink raw reply
* Re: [PATCH v12 20/46] arm64: RMI: Allow populating initial contents
From: kernel test robot @ 2025-12-20 14:34 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: llvm, oe-kbuild-all, Steven Price, 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
In-Reply-To: <20251217101125.91098-21-steven.price@arm.com>
Hi Steven,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.19-rc1 next-20251219]
[cannot apply to kvmarm/next kvm/queue kvm/next arm64/for-next/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Steven-Price/kvm-arm64-Include-kvm_emulate-h-in-kvm-arm_psci-h/20251218-030351
base: linus/master
patch link: https://lore.kernel.org/r/20251217101125.91098-21-steven.price%40arm.com
patch subject: [PATCH v12 20/46] arm64: RMI: Allow populating initial contents
config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20251220/202512202203.1g4jywFB-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512202203.1g4jywFB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512202203.1g4jywFB-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> arch/arm64/kvm/rmi.c:805:16: warning: variable 'data_flags' set but not used [-Wunused-but-set-variable]
805 | unsigned long data_flags = 0;
| ^
1 warning generated.
vim +/data_flags +805 arch/arm64/kvm/rmi.c
801
802 int kvm_arm_rmi_populate(struct kvm *kvm,
803 struct kvm_arm_rmi_populate *args)
804 {
> 805 unsigned long data_flags = 0;
806 unsigned long ipa_start = args->base;
807 unsigned long ipa_end = ipa_start + args->size;
808 int ret;
809
810 if (args->reserved ||
811 (args->flags & ~KVM_ARM_RMI_POPULATE_FLAGS_MEASURE) ||
812 !IS_ALIGNED(ipa_start, PAGE_SIZE) ||
813 !IS_ALIGNED(ipa_end, PAGE_SIZE))
814 return -EINVAL;
815
816 ret = realm_ensure_created(kvm);
817 if (ret)
818 return ret;
819
820 if (args->flags & KVM_ARM_RMI_POPULATE_FLAGS_MEASURE)
821 data_flags |= RMI_MEASURE_CONTENT;
822
823 ret = populate_region(kvm, gpa_to_gfn(ipa_start),
824 args->size >> PAGE_SHIFT,
825 args->source_uaddr, args->flags);
826
827 if (ret < 0)
828 return ret;
829
830 return ret * PAGE_SIZE;
831 }
832
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
From: kernel test robot @ 2025-12-20 14:18 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: oe-kbuild-all, Steven Price, 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
In-Reply-To: <20251217101125.91098-20-steven.price@arm.com>
Hi Steven,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20251219]
[cannot apply to kvmarm/next kvm/queue kvm/next arm64/for-next/core kvm/linux-next v6.16-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Steven-Price/kvm-arm64-Include-kvm_emulate-h-in-kvm-arm_psci-h/20251217-224409
base: linus/master
patch link: https://lore.kernel.org/r/20251217101125.91098-20-steven.price%40arm.com
patch subject: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20251220/202512201539.ZhAox5t9-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project ecaf673850beb241957352bd61e95ed34256635f)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512201539.ZhAox5t9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512201539.ZhAox5t9-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/arm64/kernel/asm-offsets.c:16:
>> ./include/linux/kvm_host.h:725:45: error: expected identifier or '('
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
>> ./include/linux/kvm_host.h:725:45: error: expected ')'
./include/linux/kvm_host.h:725:20: note: to match this '('
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
./arch/arm64/include/asm/kvm_host.h:1465:40: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
In file included from arch/arm64/kernel/asm-offsets.c:16:
./include/linux/kvm_host.h:725:20: error: expected ')'
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
./arch/arm64/include/asm/kvm_host.h:1465:45: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
./include/linux/kvm_host.h:725:20: note: to match this '('
./arch/arm64/include/asm/kvm_host.h:1465:39: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
3 errors generated.
vim +725 ./include/linux/kvm_host.h
f481b069e67437 Paolo Bonzini 2015-05-17 723
d1e54dd08f163a Fuad Tabba 2025-07-29 724 #ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
a7800aa80ea4d5 Sean Christopherson 2023-11-13 @725 static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
a7800aa80ea4d5 Sean Christopherson 2023-11-13 726 {
a7800aa80ea4d5 Sean Christopherson 2023-11-13 727 return false;
a7800aa80ea4d5 Sean Christopherson 2023-11-13 728 }
a7800aa80ea4d5 Sean Christopherson 2023-11-13 729 #endif
a7800aa80ea4d5 Sean Christopherson 2023-11-13 730
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
From: kernel test robot @ 2025-12-20 13:59 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: llvm, oe-kbuild-all, Steven Price, 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
In-Reply-To: <20251217101125.91098-20-steven.price@arm.com>
Hi Steven,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.19-rc1 next-20251219]
[cannot apply to kvmarm/next kvm/queue kvm/next arm64/for-next/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Steven-Price/kvm-arm64-Include-kvm_emulate-h-in-kvm-arm_psci-h/20251218-030351
base: linus/master
patch link: https://lore.kernel.org/r/20251217101125.91098-20-steven.price%40arm.com
patch subject: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
config: arm64-randconfig-001-20251219 (https://download.01.org/0day-ci/archive/20251220/202512202152.gapj1OD5-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b324c9f4fa112d61a553bf489b5f4f7ceea05ea8)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512202152.gapj1OD5-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512202152.gapj1OD5-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/arm64/kernel/asm-offsets.c:16:
>> include/linux/kvm_host.h:725:45: error: expected identifier or '('
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
>> include/linux/kvm_host.h:725:45: error: expected ')'
include/linux/kvm_host.h:725:20: note: to match this '('
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
arch/arm64/include/asm/kvm_host.h:1465:40: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
In file included from arch/arm64/kernel/asm-offsets.c:16:
include/linux/kvm_host.h:725:20: error: expected ')'
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^
arch/arm64/include/asm/kvm_host.h:1465:45: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
include/linux/kvm_host.h:725:20: note: to match this '('
arch/arm64/include/asm/kvm_host.h:1465:39: note: expanded from macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^
3 errors generated.
make[3]: *** [scripts/Makefile.build:182: arch/arm64/kernel/asm-offsets.s] Error 1 shuffle=1976660145
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1314: prepare0] Error 2 shuffle=1976660145
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2 shuffle=1976660145
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2 shuffle=1976660145
make: Target 'prepare' not remade because of errors.
vim +725 include/linux/kvm_host.h
f481b069e67437 Paolo Bonzini 2015-05-17 723
d1e54dd08f163a Fuad Tabba 2025-07-29 724 #ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
a7800aa80ea4d5 Sean Christopherson 2023-11-13 @725 static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
a7800aa80ea4d5 Sean Christopherson 2023-11-13 726 {
a7800aa80ea4d5 Sean Christopherson 2023-11-13 727 return false;
a7800aa80ea4d5 Sean Christopherson 2023-11-13 728 }
a7800aa80ea4d5 Sean Christopherson 2023-11-13 729 #endif
a7800aa80ea4d5 Sean Christopherson 2023-11-13 730
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
From: kernel test robot @ 2025-12-20 13:46 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: oe-kbuild-all, Steven Price, 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
In-Reply-To: <20251217101125.91098-20-steven.price@arm.com>
Hi Steven,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.19-rc1 next-20251219]
[cannot apply to kvmarm/next kvm/queue kvm/next arm64/for-next/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Steven-Price/kvm-arm64-Include-kvm_emulate-h-in-kvm-arm_psci-h/20251218-030351
base: linus/master
patch link: https://lore.kernel.org/r/20251217101125.91098-20-steven.price%40arm.com
patch subject: [PATCH v12 19/46] KVM: arm64: Expose support for private memory
config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251220/202512202102.XFW5Jfym-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512202102.XFW5Jfym-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512202102.XFW5Jfym-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/kvm_host.h:45,
from arch/arm64/kernel/asm-offsets.c:16:
>> include/linux/kvm_host.h:725:45: error: expected identifier or '(' before 'struct'
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^~~~~~
arch/arm64/include/asm/kvm_host.h:1465:41: note: in definition of macro 'kvm_arch_has_private_mem'
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^~~
>> arch/arm64/include/asm/kvm_host.h:1465:45: error: expected ')' before '->' token
1465 | #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.is_realm)
| ^~
include/linux/kvm_host.h:725:20: note: in expansion of macro 'kvm_arch_has_private_mem'
725 | static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
| ^~~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:182: arch/arm64/kernel/asm-offsets.s] Error 1
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1314: prepare0] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +725 include/linux/kvm_host.h
f481b069e67437 Paolo Bonzini 2015-05-17 723
d1e54dd08f163a Fuad Tabba 2025-07-29 724 #ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
a7800aa80ea4d5 Sean Christopherson 2023-11-13 @725 static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
a7800aa80ea4d5 Sean Christopherson 2023-11-13 726 {
a7800aa80ea4d5 Sean Christopherson 2023-11-13 727 return false;
a7800aa80ea4d5 Sean Christopherson 2023-11-13 728 }
a7800aa80ea4d5 Sean Christopherson 2023-11-13 729 #endif
a7800aa80ea4d5 Sean Christopherson 2023-11-13 730
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Huang, Kai @ 2025-12-19 21:12 UTC (permalink / raw)
To: seanjc@google.com, yilun.xu@linux.intel.com
Cc: Gao, Chao, x86@kernel.org, kas@kernel.org,
dave.hansen@linux.intel.com, mingo@redhat.com, tglx@linutronix.de,
bp@alien8.de, pbonzini@redhat.com, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org, Williams, Dan J,
kvm@vger.kernel.org
In-Reply-To: <aUVx20ZRjOzKgKqy@google.com>
On Fri, 2025-12-19 at 07:40 -0800, Sean Christopherson wrote:
> Kai, question for you (or anyone else that might know):
>
> Is there any **need** for tdx_cpu_enable() and try_init_module_global() to run
> with IRQs disabled? AFAICT, the lockdep_assert_irqs_disabled() checks added by
> commit 6162b310bc21 ("x86/virt/tdx: Add skeleton to enable TDX on demand") were
> purely because, _when the code was written_, KVM enabled virtualization via IPI
> function calls.
>
> But by the time the KVM code landed upstream in commit fcdbdf63431c ("KVM: VMX:
> Initialize TDX during KVM module load"), that was no longer true, thanks to
> commit 9a798b1337af ("KVM: Register cpuhp and syscore callbacks when enabling
> hardware") setting the stage for doing everything from task context.
The other intention was to make tdx_cpu_enable() as IRQ safe, since it was
supposed to be able to be called by multiple in-kernel users but not just
KVM (i.e., also for TDX connect).
But right currently we don't need to call them with IRQ disabled.
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Dave Hansen @ 2025-12-19 18:48 UTC (permalink / raw)
To: Sean Christopherson
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Chao Gao, Dan Williams
In-Reply-To: <aUWa8LOEJ6JeczJz@google.com>
On 12/19/25 10:35, Sean Christopherson wrote:
> I haven't tested yet, but I've got this:
>
> struct x86_virt_ops {
> int feature;
> int (*enable_virtualization_cpu)(void);
> int (*disable_virtualization_cpu)(void);
> void (*emergency_disable_virtualization_cpu)(void);
> };
> static struct x86_virt_ops virt_ops __ro_after_init;
>
> and then usage like:
>
> int x86_virt_get_ref(int feat)
> {
> int r;
>
> if (!virt_ops.feature || virt_ops.feature != feat)
> return -EOPNOTSUPP;
>
> if (this_cpu_inc_return(virtualization_nr_users) > 1)
> return 0;
>
> r = virt_ops.enable_virtualization_cpu();
> if (r)
> WARN_ON_ONCE(this_cpu_dec_return(virtualization_nr_users));
>
> return r;
> }
> EXPORT_SYMBOL_GPL(x86_virt_get_ref);
Yeah, that's much easier to follow, and fixes the naming collision thanks!
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Sean Christopherson @ 2025-12-19 18:35 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Chao Gao, Dan Williams
In-Reply-To: <90837ad5-c9a6-42da-a5a8-fcd2d870dac8@intel.com>
On Fri, Dec 19, 2025, Dave Hansen wrote:
> On 12/5/25 17:10, Sean Christopherson wrote:
> > +static int x86_vmx_get_cpu(void)
> > +{
> > + int r;
> > +
> > + if (cr4_read_shadow() & X86_CR4_VMXE)
> > + return -EBUSY;
> > +
> > + intel_pt_handle_vmx(1);
> > +
> > + r = x86_virt_cpu_vmxon();
> > + if (r) {
> > + intel_pt_handle_vmx(0);
> > + return r;
> > + }
> > +
> > + return 0;
> > +}
> ...> +#define x86_virt_call(fn) \
> > +({ \
> > + int __r; \
> > + \
> > + if (IS_ENABLED(CONFIG_KVM_INTEL) && \
> > + cpu_feature_enabled(X86_FEATURE_VMX)) \
> > + __r = x86_vmx_##fn(); \
> > + else if (IS_ENABLED(CONFIG_KVM_AMD) && \
> > + cpu_feature_enabled(X86_FEATURE_SVM)) \
> > + __r = x86_svm_##fn(); \
> > + else \
> > + __r = -EOPNOTSUPP; \
> > + \
> > + __r; \
> > +})
>
> I'm not a super big fan of this. I know you KVM folks love your macros
> and wrapping function calls in them because you hate grep. ;)
Heh, kvm_x86_call() exists _because_ I like grep and search functionality. The
number of times I couldn't find something because I was searching for full words
and forgot about the kvm_x86_ prefix...
> I don't like a foo_get_cpu() call having such fundamentally different
> semantics than good old get_cpu() itself. *Especially* when the calls
> look like:
>
> r = x86_virt_call(get_cpu);
>
> and get_cpu() itself it not invovled one bit. This 100% looks like it's
> some kind of virt-specific call for get_cpu().
>
> I think it's probably OK to make this get_hw_ref() or inc_hw_ref() or
> something to get it away from getting confused with get_cpu().
Oof, yeah, didn't think about a collision with {get,put}_cpu(). How about
x86_virt_{get,put}_ref()? I like how the callers read, e.g. "get a reference to
VMX or SVM":
x86_virt_get_ref(X86_FEATURE_VMX);
x86_virt_put_ref(X86_FEATURE_VMX);
x86_virt_get_ref(X86_FEATURE_SVM);
x86_virt_put_ref(X86_FEATURE_SVM);
> IMNHO, the macro magic is overkill. A couple of global function pointers
> would probably be fine because none of this code is even remotely
> performance sensitive. A couple static_call()s would be fine too because
> those at least make it blatantly obvious that the thing being called is
> variable. A good ol' ops structure would also make things obvious, but
> are probably also overkill-adjecent for this.
Agreed. I'm not even entirely sure why I took this approach. I suspect I carried
over the basic concept from code that wanted to run before wiring up function
pointers, and never revisited the implementation once the dust settled.
I haven't tested yet, but I've got this:
struct x86_virt_ops {
int feature;
int (*enable_virtualization_cpu)(void);
int (*disable_virtualization_cpu)(void);
void (*emergency_disable_virtualization_cpu)(void);
};
static struct x86_virt_ops virt_ops __ro_after_init;
and then usage like:
int x86_virt_get_ref(int feat)
{
int r;
if (!virt_ops.feature || virt_ops.feature != feat)
return -EOPNOTSUPP;
if (this_cpu_inc_return(virtualization_nr_users) > 1)
return 0;
r = virt_ops.enable_virtualization_cpu();
if (r)
WARN_ON_ONCE(this_cpu_dec_return(virtualization_nr_users));
return r;
}
EXPORT_SYMBOL_GPL(x86_virt_get_ref);
void x86_virt_put_ref(int feat)
{
if (WARN_ON_ONCE(!this_cpu_read(virtualization_nr_users)) ||
this_cpu_dec_return(virtualization_nr_users))
return;
BUG_ON(virt_ops.disable_virtualization_cpu() && !virt_rebooting);
}
EXPORT_SYMBOL_GPL(x86_virt_put_ref);
> P.S. In a perfect world, the renames would also be in their own patches,
> but I think I can live with it as-is.
Ya, I'll chunk the patch up.
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Dave Hansen @ 2025-12-19 17:45 UTC (permalink / raw)
To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini
Cc: linux-kernel, linux-coco, kvm, Chao Gao, Dan Williams
In-Reply-To: <20251206011054.494190-3-seanjc@google.com>
On 12/5/25 17:10, Sean Christopherson wrote:
> Move the innermost VMXON and EFER.SVME management logic out of KVM and
> into to core x86 so that TDX can force VMXON without having to rely on
> KVM being loaded, e.g. to do SEAMCALLs during initialization.
>
> Implement a per-CPU refcounting scheme so that "users", e.g. KVM and the
> future TDX code, can co-exist without pulling the rug out from under each
> other.
>
> To avoid having to choose between SVM and VMX, simply refuse to enable
> either if both are somehow supported. No known CPU supports both SVM and
> VMX, and it's comically unlikely such a CPU will ever exist.
Yeah, that's totally a "please share your drugs" moment, if it happens.
> +static int x86_vmx_get_cpu(void)
> +{
> + int r;
> +
> + if (cr4_read_shadow() & X86_CR4_VMXE)
> + return -EBUSY;
> +
> + intel_pt_handle_vmx(1);
> +
> + r = x86_virt_cpu_vmxon();
> + if (r) {
> + intel_pt_handle_vmx(0);
> + return r;
> + }
> +
> + return 0;
> +}
...> +#define x86_virt_call(fn) \
> +({ \
> + int __r; \
> + \
> + if (IS_ENABLED(CONFIG_KVM_INTEL) && \
> + cpu_feature_enabled(X86_FEATURE_VMX)) \
> + __r = x86_vmx_##fn(); \
> + else if (IS_ENABLED(CONFIG_KVM_AMD) && \
> + cpu_feature_enabled(X86_FEATURE_SVM)) \
> + __r = x86_svm_##fn(); \
> + else \
> + __r = -EOPNOTSUPP; \
> + \
> + __r; \
> +})
I'm not a super big fan of this. I know you KVM folks love your macros
and wrapping function calls in them because you hate grep. ;)
I don't like a foo_get_cpu() call having such fundamentally different
semantics than good old get_cpu() itself. *Especially* when the calls
look like:
r = x86_virt_call(get_cpu);
and get_cpu() itself it not invovled one bit. This 100% looks like it's
some kind of virt-specific call for get_cpu().
I think it's probably OK to make this get_hw_ref() or inc_hw_ref() or
something to get it away from getting confused with get_cpu().
IMNHO, the macro magic is overkill. A couple of global function pointers
would probably be fine because none of this code is even remotely
performance sensitive. A couple static_call()s would be fine too because
those at least make it blatantly obvious that the thing being called is
variable. A good ol' ops structure would also make things obvious, but
are probably also overkill-adjecent for this.
P.S. In a perfect world, the renames would also be in their own patches,
but I think I can live with it as-is.
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Dave Hansen @ 2025-12-19 17:30 UTC (permalink / raw)
To: Sean Christopherson, Xu Yilun
Cc: Chao Gao, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini, linux-kernel,
linux-coco, kvm, Dan Williams
In-Reply-To: <aUVx20ZRjOzKgKqy@google.com>
On 12/19/25 07:40, Sean Christopherson wrote:
> Is there any **need** for tdx_cpu_enable() and try_init_module_global() to run
> with IRQs disabled? AFAICT, the lockdep_assert_irqs_disabled() checks added by
> commit 6162b310bc21 ("x86/virt/tdx: Add skeleton to enable TDX on demand") were
> purely because, _when the code was written_, KVM enabled virtualization via IPI
> function calls.
Yeah, the intent was to prevent "rmmod kvm_intel" from running while TDX
was being initialized. The way it ended up, though, I think TDX init
would have been called in a KVM path _anyway_, which makes this double
useless.
^ permalink raw reply
* Re: [PATCH v2 2/7] KVM: x86: Extract VMXON and EFER.SVME enablement to kernel
From: Sean Christopherson @ 2025-12-19 15:40 UTC (permalink / raw)
To: Xu Yilun
Cc: Chao Gao, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini, linux-kernel,
linux-coco, kvm, Dan Williams
In-Reply-To: <aUS06wE6IvFti8Le@yilunxu-OptiPlex-7050>
On Fri, Dec 19, 2025, Xu Yilun wrote:
> On Wed, Dec 17, 2025 at 11:01:59AM -0800, Sean Christopherson wrote:
> > On Wed, Dec 17, 2025, Xu Yilun wrote:
> > > Is it better we explicitly assert the preemption for x86_virt_get_cpu()
> > > rather than embed the check in __this_cpu_inc_return()? We are not just
> > > protecting the racing for the reference counter. We should ensure the
> > > "counter increase + x86_virt_call(get_cpu)" can't be preempted.
> >
> > I don't have a strong preference. Using __this_cpu_inc_return() without any
> > nearby preemption_{enable,disable}() calls makes it quite clears that preemption
> > is expected to be disabled by the caller. But I'm also ok being explicit.
>
> Looking into __this_cpu_inc_return(), it finally calls
> check_preemption_disabled() which doesn't strictly requires preemption.
> It only ensures the context doesn't switch to another CPU. If the caller
> is in cpuhp context, preemption is possible.
Hmm, right, the cpuhp thread is is_percpu_thread(), and KVM's hooks aren't
considered atomic and so run with IRQs enabled. In practice, it's "fine", because
TDX also exclusively does x86_virt_get_cpu() from cpuhp, i.e. the two users are
mutually exclusive, but relying on that behavior is gross.
> But in this x86_virt_get_cpu(), we need to ensure preemption disabled,
> otherwise caller A increases counter but hasn't do actual VMXON yet and
> get preempted. Caller B opts in and get the wrong info that VMX is
> already on, and fails on following vmx operations.
>
> On a second thought, maybe we disable preemption inside
> x86_virt_get_cpu() to protect the counter-vmxon racing, this is pure
> internal thing for this kAPI.
Ya, that'd be my preference.
Kai, question for you (or anyone else that might know):
Is there any **need** for tdx_cpu_enable() and try_init_module_global() to run
with IRQs disabled? AFAICT, the lockdep_assert_irqs_disabled() checks added by
commit 6162b310bc21 ("x86/virt/tdx: Add skeleton to enable TDX on demand") were
purely because, _when the code was written_, KVM enabled virtualization via IPI
function calls.
But by the time the KVM code landed upstream in commit fcdbdf63431c ("KVM: VMX:
Initialize TDX during KVM module load"), that was no longer true, thanks to
commit 9a798b1337af ("KVM: Register cpuhp and syscore callbacks when enabling
hardware") setting the stage for doing everything from task context.
However, rather than update the kernel side, e.g. to drop the lockdep assertions
and related comments, commit 9a798b1337af instead did this:
local_irq_save(flags);
r = tdx_cpu_enable();
local_irq_restore(flags);
Somewhat frustratingly, I poked at this when the reworked code was first posted
(https://lore.kernel.org/all/ZyJOiPQnBz31qLZ7@google.com), but it just got swept
under the rug :-(
: > > + /* tdx_cpu_enable() must be called with IRQ disabled */
: >
: > I don't find this comment helpfu. If it explained _why_ tdx_cpu_enable() requires
: > IRQs to be disabled, then I'd feel differently, but as is, IMO it doesn't add value.
:
: I'll remove the comment.
:
: >
: > > + local_irq_save(flags);
: > > + r = tdx_cpu_enable();
: > > + local_irq_restore(flags);
Unless TDX _needs_ IRQs to be disabled, I would strongly prefer to drop that code
in prep patches so that it doesn't become even harder to disentagle the history
to figure out why tdx_online_cpu() disables IRQs:
static int tdx_online_cpu(unsigned int cpu)
{
int ret;
guard(irqsave)(); <=============== why is this here!?!?!
ret = x86_virt_get_cpu(X86_FEATURE_VMX);
if (ret)
return ret;
ret = tdx_cpu_enable();
if (ret)
x86_virt_put_cpu(X86_FEATURE_VMX);
return ret;
}
Side topic, KVM's change in behavior also means this comment is stale (though I
think it's worth keeping the assertion, but with a comment saying it's hardening
and paranoia, not a strick requirement).
/*
* IRQs must be disabled as virtualization is enabled in hardware via
* function call IPIs, i.e. IRQs need to be disabled to guarantee
* virtualization stays disabled.
*/
lockdep_assert_irqs_disabled();
^ permalink raw reply
* Re: [PATCH v1 26/26] coco/tdx-host: Finally enable SPDM session and IDE Establishment
From: Jonathan Cameron @ 2025-12-19 12:06 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-27-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:23:10 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> The basic SPDM session and IDE functionalities are all implemented,
> enable them.
>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
Hard to disagree with this one :)
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v1 23/26] coco/tdx-host: Parse ACPI KEYP table to init IDE for PCI host bridges
From: Jonathan Cameron @ 2025-12-19 12:02 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-24-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:23:07 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> Parse the KEYP Key Configuration Units (KCU), to decide the max IDE
> streams supported for each host bridge.
>
> The KEYP table points to a number of KCU structures that each associates
> with a list of root ports (RP) via segment, bus, and devfn. Sanity check
> the KEYP table, ensure all RPs listed for each KCU are included in one
> host bridge. Then extact the max IDE streams supported to
> pci_host_bridge via pci_ide_set_nr_streams().
>
> Co-developed-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v1 14/26] mm: Add __free() support for folio_put()
From: Jonathan Cameron @ 2025-12-19 11:55 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-15-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:58 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> Allow for the declaration of struct folio * variables that trigger
> folio_put() when they go out of scope.
>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> ---
> include/linux/mm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index d16b33bacc32..2456bb775e27 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1425,6 +1425,8 @@ static inline void folio_put(struct folio *folio)
> __folio_put(folio);
> }
>
> +DEFINE_FREE(folio_put, struct folio *, if (_T) folio_put(_T))
Seems like a reasonable addition to me.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> +
> /**
> * folio_put_refs - Reduce the reference count on a folio.
> * @folio: The folio.
^ permalink raw reply
* Re: [PATCH v1 11/26] iommu/vt-d: Cache max domain ID to avoid redundant calculation
From: Jonathan Cameron @ 2025-12-19 11:53 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-12-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:55 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> From: Lu Baolu <baolu.lu@linux.intel.com>
>
> The cap_ndoms() helper calculates the maximum available domain ID from
> the value of capability register, which can be inefficient if called
> repeatedly. Cache the maximum supported domain ID in max_domain_id field
> during initialization to avoid redundant calls to cap_ndoms() throughout
> the IOMMU driver.
>
> No functionality change.
>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Missing sign off of the last person to handle the patch. Xu Yilun.
That makes this unmergeable :(
^ permalink raw reply
* Re: [PATCH v1 12/26] iommu/vt-d: Reserve the MSB domain ID bit for the TDX module
From: Jonathan Cameron @ 2025-12-19 11:52 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-13-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:56 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> From: Lu Baolu <baolu.lu@linux.intel.com>
>
> The Intel TDX Connect Architecture Specification defines some enhancements
> for the VT-d architecture to introduce IOMMU support for TEE-IO requests.
> Section 2.2, 'Trusted DMA' states that:
>
> "I/O TLB and DID Isolation – When IOMMU is enabled to support TDX
> Connect, the IOMMU restricts the VMM’s DID setting, reserving the MSB bit
> for the TDX module. The TDX module always sets this reserved bit on the
> trusted DMA table. IOMMU tags IOTLB, PASID cache, and context entries to
> indicate whether they were created from TEE-IO transactions, ensuring
> isolation between TEE and non-TEE requests in translation caches."
>
> Reserve the MSB in the domain ID for the TDX module's use if the
> enhancement is required, which is detected if the ECAP.TDXCS bit in the
> VT-d extended capability register is set and the TVM Usable field of the
> ACPI KEYP table is set.
>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Missing sign off of the person who 'handled' the patch by sending it to
the list in this series. i.e. Xu Yilun.
One comment inline.
Thanks,
Jonathan
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index a54934c0536f..e9d65b26ad64 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -1033,6 +1033,56 @@ static int map_iommu(struct intel_iommu *iommu, struct dmar_drhd_unit *drhd)
> return err;
> }
>
> +static int keyp_config_unit_tvm_usable(union acpi_subtable_headers *header,
> + void *arg, const unsigned long end)
> +{
> + struct acpi_keyp_config_unit *acpi_cu =
> + (struct acpi_keyp_config_unit *)&header->keyp;
> + int *tvm_usable = arg;
> +
> + if (acpi_cu->flags & ACPI_KEYP_F_TVM_USABLE)
> + *tvm_usable = true;
As below. Be consistent on int vs bool as otherwise the subtle use of -1 is very confusing.
> +
> + return 0;
> +}
> +
> +static bool platform_is_tdxc_enhanced(void)
> +{
> + static int tvm_usable = -1;
> + int ret;
> +
> + /* only need to parse once */
> + if (tvm_usable != -1)
> + return tvm_usable;
> +
> + tvm_usable = false;
This is flipping between an int and a bool which seems odd.
I'd stick to an integer then make it a bool only at return.
> + ret = acpi_table_parse_keyp(ACPI_KEYP_TYPE_CONFIG_UNIT,
> + keyp_config_unit_tvm_usable, &tvm_usable);
> + if (ret < 0)
> + tvm_usable = false;
> +
> + return tvm_usable;
> +}
^ permalink raw reply
* Re: [PATCH v1 12/26] iommu/vt-d: Reserve the MSB domain ID bit for the TDX module
From: Jonathan Cameron @ 2025-12-19 11:51 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-13-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:56 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> From: Lu Baolu <baolu.lu@linux.intel.com>
>
> The Intel TDX Connect Architecture Specification defines some enhancements
> for the VT-d architecture to introduce IOMMU support for TEE-IO requests.
> Section 2.2, 'Trusted DMA' states that:
>
> "I/O TLB and DID Isolation – When IOMMU is enabled to support TDX
> Connect, the IOMMU restricts the VMM’s DID setting, reserving the MSB bit
> for the TDX module. The TDX module always sets this reserved bit on the
> trusted DMA table. IOMMU tags IOTLB, PASID cache, and context entries to
> indicate whether they were created from TEE-IO transactions, ensuring
> isolation between TEE and non-TEE requests in translation caches."
>
> Reserve the MSB in the domain ID for the TDX module's use if the
> enhancement is required, which is detected if the ECAP.TDXCS bit in the
> VT-d extended capability register is set and the TVM Usable field of the
> ACPI KEYP table is set.
>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Hi,
One comment inline.
Thanks,
Jonathan
> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
> index a54934c0536f..e9d65b26ad64 100644
> --- a/drivers/iommu/intel/dmar.c
> +++ b/drivers/iommu/intel/dmar.c
> @@ -1033,6 +1033,56 @@ static int map_iommu(struct intel_iommu *iommu, struct dmar_drhd_unit *drhd)
> return err;
> }
>
> +static int keyp_config_unit_tvm_usable(union acpi_subtable_headers *header,
> + void *arg, const unsigned long end)
> +{
> + struct acpi_keyp_config_unit *acpi_cu =
> + (struct acpi_keyp_config_unit *)&header->keyp;
> + int *tvm_usable = arg;
> +
> + if (acpi_cu->flags & ACPI_KEYP_F_TVM_USABLE)
> + *tvm_usable = true;
As below. Be consistent on int vs bool as otherwise the subtle use of -1 is very confusing.
> +
> + return 0;
> +}
> +
> +static bool platform_is_tdxc_enhanced(void)
> +{
> + static int tvm_usable = -1;
> + int ret;
> +
> + /* only need to parse once */
> + if (tvm_usable != -1)
> + return tvm_usable;
> +
> + tvm_usable = false;
This is flipping between an int and a bool which seems odd.
I'd stick to an integer then make it a bool only at return.
> + ret = acpi_table_parse_keyp(ACPI_KEYP_TYPE_CONFIG_UNIT,
> + keyp_config_unit_tvm_usable, &tvm_usable);
> + if (ret < 0)
> + tvm_usable = false;
> +
> + return tvm_usable;
> +}
^ permalink raw reply
* Re: [PATCH v1 10/26] acpi: Add KEYP support to fw_table parsing
From: Jonathan Cameron @ 2025-12-19 11:44 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-11-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:54 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> From: Dave Jiang <dave.jiang@intel.com>
>
> KEYP ACPI table can be parsed using the common fw_table handlers. Add
> additional support to detect and parse the table.
>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> Co-developed-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v1 06/26] x86/virt/tdx: Add tdx_page_array helpers for new TDX Module objects
From: Jonathan Cameron @ 2025-12-19 11:32 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-7-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:50 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> Add struct tdx_page_array definition for new TDX Module object
> types - HPA_ARRAY_T and HPA_LIST_INFO. They are used as input/output
> parameters in newly defined SEAMCALLs. Also define some helpers to
> allocate, setup and free tdx_page_array.
>
> HPA_ARRAY_T and HPA_LIST_INFO are similar in most aspects. They both
> represent a list of pages for TDX Module accessing. There are several
> use cases for these 2 structures:
>
> - As SEAMCALL inputs. They are claimed by TDX Module as control pages.
> - As SEAMCALL outputs. They were TDX Module control pages and now are
> released.
> - As SEAMCALL inputs. They are just temporary buffers for exchanging
> data blobs in one SEAMCALL. TDX Module will not hold them as control
> pages.
>
> The 2 structures both need a 'root page' which contains a list of HPAs.
> They collapse the HPA of the root page and the number of valid HPAs
> into a 64 bit raw value for SEAMCALL parameters. The root page is
> always a medium for passing data pages, TDX Module never keeps the root
> page.
>
> A main difference is HPA_ARRAY_T requires singleton mode when
> containing just 1 functional page (page0). In this mode the root page is
> not needed and the HPA field of the raw value directly points to the
> page0. But in this patch, root page is always allocated for user
> friendly kAPIs.
>
> Another small difference is HPA_LIST_INFO contains a 'first entry' field
> which could be filled by TDX Module. This simplifies host by providing
> the same structure when re-invoke the interrupted SEAMCALL. No need for
> host to touch this field.
>
> Typical usages of the tdx_page_array:
>
> 1. Add control pages:
> - struct tdx_page_array *array = tdx_page_array_create(nr_pages);
> - seamcall(TDH_XXX_CREATE, array, ...);
>
> 2. Release control pages:
> - seamcall(TDX_XXX_DELETE, array, &nr_released, &released_hpa);
> - tdx_page_array_ctrl_release(array, nr_released, released_hpa);
>
> 3. Exchange data blobs:
> - struct tdx_page_array *array = tdx_page_array_create(nr_pages);
> - seamcall(TDX_XXX, array, ...);
> - Read data from array.
> - tdx_page_array_free(array);
>
> 4. Note the root page contains 512 HPAs at most, if more pages are
> required, refilling the tdx_page_array is needed.
>
> - struct tdx_page_array *array = tdx_page_array_alloc(nr_pages);
> - for each 512-page bulk
> - tdx_page_array_fill_root(array, offset);
> - seamcall(TDH_XXX_ADD, array, ...);
>
> In case 2, SEAMCALLs output the released page array in the form of
> HPA_ARRAY_T or PAGE_LIST_INFO. tdx_page_array_ctrl_release() is
> responsible for checking if the output pages match the original input
> pages. If failed to match, the safer way is to leak the control pages,
> tdx_page_array_ctrl_leak() should be called.
>
> The usage of tdx_page_array will be in following patches.
>
> Co-developed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
One trivial comment below. I'm not going to look into tdx specifics
enough to do a detailed review of this patch.
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 09c766e60962..9a5c32dc1767 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> +static bool tdx_page_array_validate_release(struct tdx_page_array *array,
> + unsigned int offset,
> + unsigned int nr_released,
> + u64 released_hpa)
> +{
> + unsigned int nents;
> + u64 *entries;
> + int i;
> +
> + if (offset >= array->nr_pages)
> + return false;
> +
> + nents = umin(array->nr_pages - offset, TDX_PAGE_ARRAY_MAX_NENTS);
> +
> + if (nents != nr_released) {
> + pr_err("%s nr_released [%d] doesn't match page array nents [%d]\n",
> + __func__, nr_released, nents);
> + return false;
> + }
> +
> + /*
> + * Unfortunately TDX has multiple page allocation protocols, check the
> + * "singleton" case required for HPA_ARRAY_T.
> + */
> + if (page_to_phys(array->pages[0]) == released_hpa &&
> + array->nr_pages == 1)
> + return true;
> +
> + /* Then check the "non-singleton" case */
> + if (page_to_phys(array->root) == released_hpa) {
> + entries = (u64 *)page_address(array->root);
page_address() returns a void * so the cast here isn't needed and (to me
at least) doesn't add value from readability point of view.
I haven't checked later patches, but if this code doesn't change to use
entries outside this scope then,
u64 *entries = page_address(array->root);
would be nice to restrict the scope and make the type here immediately
visible.
> + for (i = 0; i < nents; i++) {
> + struct page *page = array->pages[offset + i];
> + u64 val = page_to_phys(page);
> +
> + if (val != entries[i]) {
> + pr_err("%s entry[%d] [0x%llx] doesn't match page hpa [0x%llx]\n",
> + __func__, i, entries[i], val);
> + return false;
> + }
> + }
> +
> + return true;
> + }
> +
> + pr_err("%s failed to validate, released_hpa [0x%llx], root page hpa [0x%llx], page0 hpa [%#llx], number pages %u\n",
> + __func__, released_hpa, page_to_phys(array->root),
> + page_to_phys(array->pages[0]), array->nr_pages);
> +
> + return false;
> +}
^ permalink raw reply
* Re: [PATCH v1 05/26] mm: Add __free() support for __free_page()
From: Jonathan Cameron @ 2025-12-19 11:22 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-6-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:49 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> Allow for the declaration of struct page * variables that trigger
> __free_page() when they go out of scope.
>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> include/linux/gfp.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 0ceb4e09306c..dc61fa63a3b9 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -383,6 +383,7 @@ extern void free_pages_nolock(struct page *page, unsigned int order);
> extern void free_pages(unsigned long addr, unsigned int order);
>
> #define __free_page(page) __free_pages((page), 0)
> +DEFINE_FREE(__free_page, struct page *, if (_T) __free_page(_T))
> #define free_page(addr) free_pages((addr), 0)
>
> void page_alloc_init_cpuhp(void);
^ permalink raw reply
* Re: [PATCH v1 01/26] coco/tdx-host: Introduce a "tdx_host" device
From: Jonathan Cameron @ 2025-12-19 11:19 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-coco, linux-pci, chao.gao, dave.jiang, baolu.lu, yilun.xu,
zhenzhong.duan, kvm, rick.p.edgecombe, dave.hansen,
dan.j.williams, kas, x86
In-Reply-To: <20251117022311.2443900-2-yilun.xu@linux.intel.com>
On Mon, 17 Nov 2025 10:22:45 +0800
Xu Yilun <yilun.xu@linux.intel.com> wrote:
> From: Chao Gao <chao.gao@intel.com>
>
> TDX depends on a platform firmware module that is invoked via instructions
> similar to vmenter (i.e. enter into a new privileged "root-mode" context to
> manage private memory and private device mechanisms). It is a software
> construct that depends on the CPU vmxon state to enable invocation of
> TDX-module ABIs. Unlike other Trusted Execution Environment (TEE) platform
> implementations that employ a firmware module running on a PCI device with
> an MMIO mailbox for communication, TDX has no hardware device to point to
> as the TEE Secure Manager (TSM).
>
> Create a virtual device not only to align with other implementations but
> also to make it easier to
>
> - expose metadata (e.g., TDX module version, seamldr version etc) to
> the userspace as device attributes
>
> - implement firmware uploader APIs which are tied to a device. This is
> needed to support TDX module runtime updates
>
> - enable TDX Connect which will share a common infrastructure with other
> platform implementations. In the TDX Connect context, every
> architecture has a TSM, represented by a PCIe or virtual device. The
> new "tdx_host" device will serve the TSM role.
>
> A faux device is used as for TDX because the TDX module is singular within
> the system and lacks associated platform resources. Using a faux device
> eliminates the need to create a stub bus.
>
> The call to tdx_enable() makes the new module independent of kvm_intel.ko.
> For example, TDX Connect may be used to established to PCIe link encryption
> even if a TVM is never launched. For now, just create the common loading
> infrastructure.
>
> [ Yilun: Remove unnecessary head files ]
> Co-developed-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
LGTM
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ 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