TDX KVM selftests

Quoted 6 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +6 -0

+
+static const struct kvm_tdx_capabilities *tdx_read_capabilities(struct kvm_vm *vm)
+{
+	static struct kvm_tdx_capabilities *tdx_cap;
+	int nr_cpuid_configs = 4;
+	int rc = -1;

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c line 20

Quoted 10 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +10 -0

+	int i;
+
+	if (tdx_cap)
+		return tdx_cap;
+
+	do {
+		nr_cpuid_configs *= 2;
+
+		tdx_cap = realloc(tdx_cap, sizeof(*tdx_cap) +
+					   (sizeof(struct kvm_cpuid_entry2) * nr_cpuid_configs));

[Severity: Medium]
Could this realloc() cause a data race if multiple threads attempt to create TDX VMs concurrently?

If tdx_read_capabilities() checks and reallocates the static pointer tdx_cap without locking, concurrent calls might race on the realloc(), potentially leading to memory corruption, a double free, or a use-after-free during test execution.

[ ... ]

Quoted 7 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +7 -0

+void tdx_init_vm(struct kvm_vm *vm)
+{
+	struct kvm_tdx_init_vm *init_vm;
+	const struct kvm_cpuid2 *tmp;
+	struct kvm_cpuid2 *cpuid;
+
+	tmp = kvm_get_supported_cpuid();

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c line 112

Quoted 10 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +10 -0

+
+	cpuid = allocate_kvm_cpuid2(tmp->nent);
+	memcpy(cpuid, tmp, kvm_cpuid2_size(tmp->nent));
+	tdx_filter_cpuid(vm, cpuid);
+
+	init_vm = calloc(1, sizeof(*init_vm) +
+			 sizeof(init_vm->cpuid.entries[0]) * cpuid->nent);
+	TEST_ASSERT(init_vm, "init_vm allocation failed");
+
+	memcpy(&init_vm->cpuid, cpuid, kvm_cpuid2_size(cpuid->nent));

[Severity: Medium]
Does this memcpy() copy uninitialized padding into the ioctl payload?

Since allocate_kvm_cpuid2() allocates struct kvm_cpuid2 using malloc(), the padding field can be left uninitialized. The kernel's KVM_GET_SUPPORTED_CPUID ioctl does not clear this padding, and it is subsequently copied into init_vm->cpuid here.

Because the KVM_TDX_INIT_VM ioctl strictly validates that cpuid.padding is zero, could this cause KVM_TDX_INIT_VM to fail with -EINVAL if the padding contains garbage?

From: Sagi Shahar <[email protected]>

Add tdx_init_vm() to handle the mandatory VM-level initialization sequence required for Intel TDX.

For TDX, the VM's CPUID configuration must be "sealed" during KVM_TDX_INIT_VM before any vCPUs are created. This is necessary because the TDX module does not allow the host to create and initialize any vCPUs before the VM's CPUID configuration is accepted and sealed into the TDCS.

Additionally, to satisfy the strict requirements of the TDH.MNG.INIT SEAMCALL, the helper masks the host-supported CPUID

(kvm_get_supported_cpuid()) against the "directly configurable"bits reported by KVM_TDX_CAPABILITIES.

Co-developed-by Isaku Yamahata <[email protected]>

Signed-off-by Isaku Yamahata <[email protected]>

Co-developed-by Rick Edgecombe <[email protected]>

Signed-off-by Rick Edgecombe <[email protected]>

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

---
 tools/testing/selftests/kvm/Makefile.kvm           |   1 +
 .../testing/selftests/kvm/include/x86/processor.h  |   2 +
 .../selftests/kvm/include/x86/tdx/tdx_util.h       |  37 +++++++
 tools/testing/selftests/kvm/lib/x86/processor.c    |  21 +++-
 tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c | 121 +++++++++++++++++++++
 5 files changed, 178 insertions(+), 4 deletions(-)

tools/testing/selftests/kvm/Makefile.kvm +1 -0

index 239bc61ea384..8f514008daa2 100644
@@ -28,6 +28,7 @@ LIBKVM_x86 += lib/x86/pmu.c
 LIBKVM_x86 += lib/x86/processor.c
 LIBKVM_x86 += lib/x86/sev.c
 LIBKVM_x86 += lib/x86/svm.c
+LIBKVM_x86 += lib/x86/tdx/tdx_util.c
 LIBKVM_x86 += lib/x86/ucall.c
 LIBKVM_x86 += lib/x86/vmx.c
 

tools/testing/selftests/kvm/include/x86/processor.h +2 -0

index ed50007e3504..08b7b194f213 100644
@@ -1024,6 +1024,8 @@ static inline void vcpu_xcrs_set(struct kvm_vcpu *vcpu, struct kvm_xcrs *xcrs)
 	vcpu_ioctl(vcpu, KVM_SET_XCRS, xcrs);
 }
 
+const struct kvm_cpuid_entry2 *__get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
+						 u32 function, u32 index);
 const struct kvm_cpuid_entry2 *get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
 					       u32 function, u32 index);
 const struct kvm_cpuid2 *kvm_get_supported_cpuid(void);

tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h +23 -0

index f647e6ca6b34..571f7ce4b8fe 100644
@@ -11,4 +11,41 @@ static inline bool is_tdx_vm(struct kvm_vm *vm)
 	return vm->type == KVM_X86_TDX_VM;
 }
 
+/*
+ * TDX ioctls
+ * Use underscores to avoid collisions with struct member names.
+ */
+#define __tdx_vm_ioctl(vm, cmd, _flags, arg, hw_err)			\
+({									\
+	u64 *__hw_err = (hw_err);					\
+	int r;								\
+									\
+	union {								\
+		struct kvm_tdx_cmd c;					\
+		unsigned long raw;					\
+	} tdx_cmd = { .c = {						\
+		.id = (cmd),						\
+		.flags = (u32)(_flags),					\
+		.data = (u64)(arg),					\
+	} };								\
+									\
+	r = __vm_ioctl(vm, KVM_MEMORY_ENCRYPT_OP, &tdx_cmd.raw);	\
+	if (__hw_err)							\
+		*__hw_err = tdx_cmd.c.hw_error;				\
+	r;								\
+})

tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h +4 -0

+})
+
+void tdx_init_vm(struct kvm_vm *vm);
+
 #endif /* SELFTESTS_TDX_TDX_UTIL_H */

tools/testing/selftests/kvm/lib/x86/processor.c +17 -4

index 24395a8e654a..b87ba7d8538b 100644
@@ -829,6 +829,9 @@ void kvm_arch_vm_post_create(struct kvm_vm *vm, unsigned int nr_vcpus)
 		vm_sev_ioctl(vm, KVM_SEV_INIT2, &init);
 	}
 
+	if (is_tdx_vm(vm))
+		tdx_init_vm(vm);
+
 	r = __vm_ioctl(vm, KVM_GET_TSC_KHZ, NULL);
 	TEST_ASSERT(r > 0, "KVM_GET_TSC_KHZ did not provide a valid TSC frequency.");
 	guest_tsc_khz = r;

@@ -1347,8 +1350,8 @@ void kvm_init_vm_address_properties(struct kvm_vm *vm)
 	}
 }
 
-const struct kvm_cpuid_entry2 *get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
-					       u32 function, u32 index)
+const struct kvm_cpuid_entry2 *__get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
+						 u32 function, u32 index)
 {
 	int i;
 

@@ -1358,11 +1361,21 @@ const struct kvm_cpuid_entry2 *get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
 			return &cpuid->entries[i];
 	}
 
-	TEST_FAIL("CPUID function 0x%x index 0x%x not found ", function, index);
-
 	return NULL;
 }
 
+const struct kvm_cpuid_entry2 *get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
+					       u32 function, u32 index)
+{
+	const struct kvm_cpuid_entry2 *entry;
+
+	entry = __get_cpuid_entry(cpuid, function, index);
+	if (!entry)
+		TEST_FAIL("CPUID function 0x%x index 0x%x not found ", function, index);
+
+	return entry;
+}
+
 #define X86_HYPERCALL(inputs...)					\
 ({									\
 	u64 r;							\

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +12 -0

new file mode 100644
index 000000000000..3a8900ff2540
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "processor.h"
+#include "tdx/tdx_util.h"
+
+static const struct kvm_tdx_capabilities *tdx_read_capabilities(struct kvm_vm *vm)
+{
+	static struct kvm_tdx_capabilities *tdx_cap;
+	int nr_cpuid_configs = 4;
+	int rc = -1;
+	int i;
+

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +22 -0

+			    nr_cpuid_configs);
+
+		tdx_cap->cpuid.nent = nr_cpuid_configs;
+		rc = __tdx_vm_ioctl(vm, KVM_TDX_CAPABILITIES, 0, tdx_cap, NULL);
+	} while (rc < 0 && errno == E2BIG);
+
+	TEST_ASSERT(rc == 0, "KVM_TDX_CAPABILITIES failed: %d %d",
+		    rc, errno);
+
+	pr_debug("tdx_cap: supported_attrs: 0x%016llx\n"
+		 "tdx_cap: supported_xfam 0x%016llx\n",
+		 tdx_cap->supported_attrs, tdx_cap->supported_xfam);
+
+	for (i = 0; i < tdx_cap->cpuid.nent; i++) {
+		const struct kvm_cpuid_entry2 *config = &tdx_cap->cpuid.entries[i];
+
+		pr_debug("cpuid config[%d]: leaf 0x%x sub_leaf 0x%x eax 0x%08x ebx 0x%08x ecx 0x%08x edx 0x%08x\n",
+			 i, config->function, config->index,
+			 config->eax, config->ebx, config->ecx, config->edx);
+	}
+
+	return tdx_cap;

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +47 -0

+ */
+static void tdx_filter_cpuid(struct kvm_vm *vm,
+			     struct kvm_cpuid2 *cpuid_data)
+{
+	const struct kvm_tdx_capabilities *tdx_cap;
+	const struct kvm_cpuid_entry2 *config;
+	struct kvm_cpuid_entry2 *e;
+	int i;
+
+	tdx_cap = tdx_read_capabilities(vm);
+
+	i = 0;
+	while (i < cpuid_data->nent) {
+		e = cpuid_data->entries + i;
+		config = __get_cpuid_entry(&tdx_cap->cpuid, e->function, e->index);
+
+		if (!config) {
+			int left = cpuid_data->nent - i - 1;
+
+			if (left > 0)
+				memmove(cpuid_data->entries + i,
+					cpuid_data->entries + i + 1,
+					sizeof(*cpuid_data->entries) * left);
+			cpuid_data->nent--;
+			continue;
+		}
+
+		e->eax &= config->eax;
+		e->ebx &= config->ebx;
+		e->ecx &= config->ecx;
+		e->edx &= config->edx;
+
+		i++;
+	}
+}
+
+void tdx_init_vm(struct kvm_vm *vm)
+{
+	struct kvm_tdx_init_vm *init_vm;
+	const struct kvm_cpuid2 *tmp;
+	struct kvm_cpuid2 *cpuid;
+
+	tmp = kvm_get_supported_cpuid();
+
+	cpuid = allocate_kvm_cpuid2(tmp->nent);
+	memcpy(cpuid, tmp, kvm_cpuid2_size(tmp->nent));
+	tdx_filter_cpuid(vm, cpuid);

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c new file +5 -0

+
+	tdx_vm_ioctl(vm, KVM_TDX_INIT_VM, 0, init_vm);
+
+	free(init_vm);
+}

From: Sagi Shahar <[email protected]>

Add the Kbuild macros needed to enable the filechk_offsets mechanism to generate C header files containing structure member offset information.

Tools depending on assembly code that operate on structures have to hardcode the offsets of structure members. The Kbuild infrastructure can instead generate C header files with these offsets automatically, allowing them to be included in assembly code as symbolic constants.

For example, the TDX guest boot code requires access to parameters passed in the C structure (struct td_boot_parameters). This header provides the macros needed to extract these offsets from C code and expose them to assembly, ensuring the two remain synchronized.

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

Reviewed-by Ackerley Tng <[email protected]>

Reviewed-by Binbin Wu <[email protected]>

---
 tools/include/linux/kbuild.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

tools/include/linux/kbuild.h new file +11 -0

new file mode 100644
index 000000000000..957fd55cd159
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __TOOLS_LINUX_KBUILD_H
+#define __TOOLS_LINUX_KBUILD_H
+
+#define DEFINE(sym, val) \
+	asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
+
+#define OFFSET(sym, str, mem) \
+	DEFINE(sym, __builtin_offsetof(struct str, mem))
+
+#endif /* __TOOLS_LINUX_KBUILD_H */

tools/testing/selftests/kvm/Makefile.kvm +2 -0

+LIBKVM_ASM_DEFS_OBJ := $(patsubst %.c, $(OUTPUT)/%.s, $(LIBKVM_ASM_DEFS))
+LIBKVM_OBJS = $(LIBKVM_C_OBJ) $(LIBKVM_S_OBJ) $(LIBKVM_STRING_OBJ) $(LIBCGROUP_O) $(LIBVFIO_O)
 SPLIT_TEST_GEN_PROGS := $(patsubst %, $(OUTPUT)/%, $(SPLIT_TESTS))
 SPLIT_TEST_GEN_OBJ := $(patsubst %, $(OUTPUT)/$(ARCH)/%.o, $(SPLIT_TESTS))

[ ... ]

tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S line 29

Quoted 7 lines

tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S new file +7 -0

+	/*
+	 * Find the address of struct td_per_vcpu_parameters for this
+	 * vCPU based on esi (TDX spec: initialized with vCPU id). Put
+	 * struct address into eax for indirect addressing.
+	 */
+	movl $SIZEOF_TD_PER_VCPU_PARAMETERS, %eax
+	mul %esi

[Severity: Medium]
Is it correct to read the vCPU index from %esi in td_boot here?

According to the TDX architecture specification (via TDH.VP.INIT), the vCPU index is initialized in the %ecx register, while %esi is initialized to 0.

If %esi is used, will all vCPUs evaluate to index 0, causing them to incorrectly share the same stack and guest code pointer? This seems like it could corrupt the SMP stack and fail multi-vCPU tests.

[ ... ]

tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S line 56

Quoted 13 lines

tools/testing/selftests/kvm/lib/x86/tdx/td_boot.S new file +13 -0

+	/*
+	 * Set up control registers (x86 does not support moving memory
+	 * directly to a control register).
+	 */
+	movl TD_BOOT_PARAMETERS_CR4(%ebx), %edi
+	movl %edi, %cr4
+	movl TD_BOOT_PARAMETERS_CR3(%ebx), %edi
+	movl %edi, %cr3
+	movl TD_BOOT_PARAMETERS_CR0(%ebx), %edi
+	movl %edi, %cr0
+
+	/* Switching to 64bit mode after ljmp and then jump to guest code */
+	ljmp $(KERNEL_CS),$1f

[Severity: Medium]
Does td_boot miss a wrmsr to set EFER.LME before enabling paging?

The TDX VM guest boot code enables paging (CR0.PG) and physical address extensions (CR4.PAE) here, but appears to omit writing the EFER MSR to set the Long Mode Enable (LME) bit.

According to the x86 architecture, enabling paging without setting EFER.LME puts the processor into 32-bit PAE paging mode instead of 64-bit IA-32e mode.

Will the subsequent far jump attempt to load a 64-bit code segment (KERNEL_CS has L=1), causing a #GP fault since it is invalid in 32-bit mode? It seems this might crash the guest VM unconditionally on every boot.

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7

[ ... ]

Quoted 5 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +5 -0

+	/* Set parameters! */
+	params->cr0 = kvm_get_default_cr0();
+	TEST_ASSERT(vm->mmu.pgd < (1ULL << 32),
+		    "PGD must be within 32-bit address space for 32-bit boot code");
+	params->cr3 = vm->mmu.pgd;

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c void tdx_vm_setup_boot_code_region(struct kvm_vm *vm) · line 86

Quoted 10 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +10 -0

+	params->cr4 = cr4;
+	params->idtr.base = vm->arch.idt;
+	params->idtr.limit = kvm_get_default_idt_limit();
+	params->gdtr.base = vm->arch.gdt;
+	params->gdtr.limit = kvm_get_default_gdt_limit();
+
+	TEST_ASSERT(params->idtr.base < (1ULL << 32),
+		    "idt must be within 32-bit address space for 32-bit boot code");
+	TEST_ASSERT(params->gdtr.base < (1ULL << 32),
+		    "gdt must be within 32-bit address space for 32-bit boot code");

[Severity: Low]
Does this assignment silently truncate the 64-bit vm->arch.idt and vm->arch.gdt addresses?

Since params->idtr.base and params->gdtr.base are 32-bit fields, the subsequent TEST_ASSERT checks evaluate the already-truncated values. If a test allocates an IDT or GDT address beyond 4GB, the assertions will always be trivially true because the upper 32 bits are lost before the check.

This could lead to confusing test failures during guest execution instead of properly failing the assertion here.

Should these assertions check vm->arch.idt and vm->arch.gdt directly before assigning them to the base fields?

From: Sagi Shahar <[email protected]>

Allocate memory for TDX boot parameters and define the utility functions necessary to fill this memory with the boot parameters.

Co-developed-by Ackerley Tng <[email protected]>

Signed-off-by Ackerley Tng <[email protected]>

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

From: Sagi Shahar <[email protected]>

Allocate memory for TDX boot parameters and define the utility functions necessary to fill this memory with the boot parameters.

Co-developed-by Ackerley Tng <[email protected]>

Signed-off-by Ackerley Tng <[email protected]>

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +4 -0

+
+	virt_map(vm, TD_BOOT_PARAMETERS_GPA, TD_BOOT_PARAMETERS_GPA, npages);
+}
+

The default attributes for guest_memfd pages without in-place conversion is private.

However, the ucall pages need to be shared between the host and the guest. Thus, set them as shared.

Signed-off-by Lisa Wang <[email protected]>

---
 tools/testing/selftests/kvm/lib/ucall_common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

tools/testing/selftests/kvm/lib/ucall_common.c +8 -0

index 029ce21f9f2f..c03dfc763172 100644
@@ -27,6 +27,7 @@ static struct ucall_header *ucall_pool;
 
 void ucall_init(struct kvm_vm *vm, gpa_t mmio_gpa)
 {
+	struct userspace_mem_region *region;
 	struct ucall_header *hdr;
 	struct ucall *uc;
 	gva_t gva;

@@ -37,6 +38,13 @@ void ucall_init(struct kvm_vm *vm, gpa_t mmio_gpa)
 	hdr = (struct ucall_header *)addr_gva2hva(vm, gva);
 	memset(hdr, 0, sizeof(*hdr));
 
+	region = vm_get_mem_region(vm, MEM_REGION_DATA);
+	if (region->region.flags & KVM_MEM_GUEST_MEMFD) {
+		size_t aligned_sz = align_up(sizeof(*hdr), vm->page_size);
+
+		vm_mem_set_shared(vm, addr_gva2gpa(vm, gva), aligned_sz);
+	}
+
 	for (i = 0; i < KVM_MAX_VCPUS; ++i) {
 		uc = &hdr->ucalls[i];
 		uc->hva = uc;

Quoted 2 lines · Lisa Wang

The default attributes for guest_memfd pages without in-place conversion is private.

This is wrong. The default memory attribute is of a @gfn is shared without in-place conversion, i.e., with per-vm memory attribute.

We don't need this patch actually. And I have tested with reverting this patch, with both out of place conversion and in-place conversion. Both worked.

Force guest_memfd for TDX VMs.

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Binbin Wu <[email protected]>

---
 tools/testing/selftests/kvm/lib/kvm_util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/testing/selftests/kvm/lib/kvm_util.c +1 -1

index 3f559f207408..7625908caf21 100644
@@ -482,7 +482,7 @@ void kvm_set_files_rlimit(u32 nr_vcpus)
 static bool is_guest_memfd_required(struct vm_shape shape)
 {
 #ifdef __x86_64__
-	return shape.type == KVM_X86_SNP_VM;
+	return shape.type == KVM_X86_SNP_VM || shape.type == KVM_X86_TDX_VM;
 #else
 	return false;
 #endif

With guest_memfd in-place conversion, the memory region can be set as shared, eliminating the need for dual-backed memory.

By setting the region to shared initially, the KVM selftest framework can populate the mmap()-ed guest_memfd memory just like any standard memory provider.

For CoCo VMs, pages that need to be private are explicitly set to private before executing the VM.

Signed-off-by Lisa Wang <[email protected]>

---
 tools/testing/selftests/kvm/lib/kvm_util.c         | 20 ++++++++++++++------
 tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c |  6 +++++-
 2 files changed, 19 insertions(+), 7 deletions(-)

tools/testing/selftests/kvm/lib/kvm_util.c +7 -5

index 7625908caf21..f474664b5d92 100644
@@ -494,8 +494,10 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
 	u64 nr_pages = vm_nr_pages_required(shape.mode, nr_runnable_vcpus,
 						 nr_extra_pages);
 	struct userspace_mem_region *slot0;
+	u64 gmem_flags = 0;
 	struct kvm_vm *vm;
-	int i, flags;
+	int flags = 0;
+	int i;
 
 	kvm_set_files_rlimit(nr_runnable_vcpus);
 

@@ -505,14 +507,20 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
 	vm = ____vm_create(shape);
 
 	/*
-	 * Force GUEST_MEMFD for the primary memory region if necessary, e.g.
-	 * for CoCo VMs that require GUEST_MEMFD backed private memory.
+	 * Force GUEST_MEMFD for the primary memory region if necessary, and
+	 * initialize it as shared if in-place conversion is supported, so the
+	 * selftest framework can populate it exactly like other memory
+	 * providers.
 	 */
-	flags = 0;
-	if (is_guest_memfd_required(shape))

tools/testing/selftests/kvm/lib/kvm_util.c +0 -0

 	for (i = 0; i < NR_MEM_REGIONS; i++)
 		vm->memslots[i] = 0;
 

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +5 -1

index e348507a6be8..40ee9b1951c2 100644
@@ -23,6 +23,8 @@ void tdx_vm_setup_boot_code_region(struct kvm_vm *vm)
 	gpa_t gpa;
 	u8 *hva;
 
+	if (kvm_has_gmem_attributes)
+		gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED | GUEST_MEMFD_FLAG_MMAP;
 	vm_mem_add(vm, VM_MEM_SRC_SHMEM, alloc_gpa, TD_BOOT_CODE_SLOT,
 		   nr_pages, KVM_MEM_GUEST_MEMFD, -1, 0, gmem_flags);
 

@@ -44,9 +46,11 @@ void tdx_vm_setup_boot_parameters_region(struct kvm_vm *vm, u32 nr_runnable_vcpu
 	size_t boot_params_size = sizeof(struct td_boot_parameters) +
 		nr_runnable_vcpus * sizeof(struct td_per_vcpu_parameters);
 	int npages = DIV_ROUND_UP(boot_params_size, PAGE_SIZE);
-	const u64 gmem_flags = 0;
+	u64 gmem_flags = 0;
 	gpa_t gpa;
 
+	if (kvm_has_gmem_attributes)
+		gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED | GUEST_MEMFD_FLAG_MMAP;
 	vm_mem_add(vm, VM_MEM_SRC_SHMEM, TD_BOOT_PARAMETERS_GPA,
 		   TD_BOOT_PARAMETERS_SLOT, npages,
 		   KVM_MEM_GUEST_MEMFD, -1, 0, gmem_flags);

Quoted 52 lines · Lisa Wang

With guest_memfd in-place conversion, the memory region can be set as shared, eliminating the need for dual-backed memory.

By setting the region to shared initially, the KVM selftest framework can populate the mmap()-ed guest_memfd memory just like any standard memory provider.

For CoCo VMs, pages that need to be private are explicitly set to private before executing the VM.

Signed-off-by Lisa Wang <[email protected]>

---
 tools/testing/selftests/kvm/lib/kvm_util.c         | 20 ++++++++++++++------
 tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c |  6 +++++-
 2 files changed, 19 insertions(+), 7 deletions(-)

tools/testing/selftests/kvm/lib/kvm_util.c +12 -5

index 7625908caf21..f474664b5d92 100644
@@ -494,8 +494,10 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
 	u64 nr_pages = vm_nr_pages_required(shape.mode, nr_runnable_vcpus,
 						 nr_extra_pages);
 	struct userspace_mem_region *slot0;
+	u64 gmem_flags = 0;
 	struct kvm_vm *vm;
-	int i, flags;
+	int flags = 0;
+	int i;
 
 	kvm_set_files_rlimit(nr_runnable_vcpus);
 

@@ -505,14 +507,20 @@ struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus,
 	vm = ____vm_create(shape);
 
 	/*
-	 * Force GUEST_MEMFD for the primary memory region if necessary, e.g.
-	 * for CoCo VMs that require GUEST_MEMFD backed private memory.
+	 * Force GUEST_MEMFD for the primary memory region if necessary, and
+	 * initialize it as shared if in-place conversion is supported, so the
+	 * selftest framework can populate it exactly like other memory
+	 * providers.
 	 */
-	flags = 0;
-	if (is_guest_memfd_required(shape))
+	if (is_guest_memfd_required(shape)) {
 		flags |= KVM_MEM_GUEST_MEMFD;
+		if (kvm_has_gmem_attributes)
+			gmem_flags |= GUEST_MEMFD_FLAG_INIT_SHARED |
+				      GUEST_MEMFD_FLAG_MMAP;
+	}
 

tools/testing/selftests/kvm/lib/kvm_util.c struct kvm_vm *__vm_create(struct vm_shape shape, u32 nr_runnable_vcpus, · line 523

Quoted 3 lines

tools/testing/selftests/kvm/lib/kvm_util.c +2 -1

-	vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags);
+	vm_mem_add(vm, VM_MEM_SRC_ANONYMOUS, 0, 0, nr_pages, flags,
+		   -1, 0, gmem_flags);

This is common for both TDX and SNP, does it break SNP?

From: Sagi Shahar <[email protected]>

Introduce kvm_allocate_vcpu_stack() to allocate a vCPU's stack in preparation for TDX to allocate a vCPU's stack and initialize its stack pointer.

TDX VMs' registers are protected state and cannot be initialized using the KVM_SET_REGS ioctl() that is used for normal VMs. A TDX vCPU's stack address will be a property of the TDX specific boot code that initializes the vCPUs' stack pointers at boot.

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Binbin Wu <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

Reviewed-by Xiaoyao Li <[email protected]>

---
 .../testing/selftests/kvm/include/x86/processor.h  |  2 ++
 tools/testing/selftests/kvm/lib/x86/processor.c    | 25 +++++++++++++++++++---
 2 files changed, 24 insertions(+), 3 deletions(-)

tools/testing/selftests/kvm/include/x86/processor.h +2 -0

index 8854ee052d29..1eb380dd216c 100644
@@ -1212,6 +1212,8 @@ static inline void vcpu_clear_cpuid_feature(struct kvm_vcpu *vcpu,
 	vcpu_set_or_clear_cpuid_feature(vcpu, feature, false);
 }
 
+gva_t kvm_allocate_vcpu_stack(struct kvm_vm *vm);
+
 u64 vcpu_get_msr(struct kvm_vcpu *vcpu, u64 msr_index);
 int _vcpu_set_msr(struct kvm_vcpu *vcpu, u64 msr_index, u64 msr_value);
 

tools/testing/selftests/kvm/lib/x86/processor.c +0 -0

index da430d4e7765..4a753fb43007 100644

tools/testing/selftests/kvm/lib/x86/processor.c +21 -2

 {
 	struct kvm_mp_state mp_state;
 	struct kvm_regs regs;
+	gva_t stack_gva;
 	struct kvm_vcpu *vcpu;
 
+	stack_gva = __vm_alloc(vm, DEFAULT_STACK_PGS * getpagesize(),
+			       DEFAULT_GUEST_STACK_VADDR_MIN, MEM_REGION_DATA);
+
+	stack_gva += DEFAULT_STACK_PGS * getpagesize();
+
+	/*
+	 * Align stack to match calling sequence requirements in section "The
+	 * Stack Frame" of the System V ABI AMD64 Architecture Processor
+	 * Supplement, which requires the value (%rsp + 8) to be a multiple of
+	 * 16 when control is transferred to the function entry point.
+	 *
+	 * If this code is ever used to launch a vCPU with 32-bit entry point it
+	 * may need to subtract 4 bytes instead of 8 bytes.
+	 */
+	TEST_ASSERT(IS_ALIGNED(stack_gva, PAGE_SIZE),
+		    "__vm_alloc() did not provide a page-aligned address");
+	stack_gva -= 8;
+
 	vcpu = __vm_vcpu_add(vm, vcpu_id);
 	vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
 	vcpu_init_sregs(vm, vcpu);

@@ -864,8 +883,8 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
 
 	/* Setup guest general purpose registers */
 	vcpu_regs_get(vcpu, &regs);
-	regs.rflags = regs.rflags | X86_EFLAGS_FIXED;
-	regs.rsp = vm_alloc_stack(vm, DEFAULT_STACK_PGS);
+	regs.rflags = regs.rflags | 0x2;
+	regs.rsp = kvm_allocate_vcpu_stack(vm);
 	vcpu_regs_set(vcpu, &regs);
 
 	/* Setup the MP state */

Quoted 42 lines · Lisa Wang

From: Sagi Shahar <[email protected]>

Introduce kvm_allocate_vcpu_stack() to allocate a vCPU's stack in preparation for TDX to allocate a vCPU's stack and initialize its stack pointer.

TDX VMs' registers are protected state and cannot be initialized using the KVM_SET_REGS ioctl() that is used for normal VMs. A TDX vCPU's stack address will be a property of the TDX specific boot code that initializes the vCPUs' stack pointers at boot.

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Binbin Wu <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

Reviewed-by Xiaoyao Li <[email protected]>

---
 .../testing/selftests/kvm/include/x86/processor.h  |  2 ++
 tools/testing/selftests/kvm/lib/x86/processor.c    | 25 +++++++++++++++++++---
 2 files changed, 24 insertions(+), 3 deletions(-)

tools/testing/selftests/kvm/include/x86/processor.h +2 -0

index 8854ee052d29..1eb380dd216c 100644
@@ -1212,6 +1212,8 @@ static inline void vcpu_clear_cpuid_feature(struct kvm_vcpu *vcpu,
 	vcpu_set_or_clear_cpuid_feature(vcpu, feature, false);
 }
 
+gva_t kvm_allocate_vcpu_stack(struct kvm_vm *vm);
+
 u64 vcpu_get_msr(struct kvm_vcpu *vcpu, u64 msr_index);
 int _vcpu_set_msr(struct kvm_vcpu *vcpu, u64 msr_index, u64 msr_value);
 

tools/testing/selftests/kvm/lib/x86/processor.c +0 -0

index da430d4e7765..4a753fb43007 100644
@@ -851,12 +851,31 @@ void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code)
 	vcpu_regs_set(vcpu, &regs);
 }
 

tools/testing/selftests/kvm/lib/x86/processor.c void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code) · line 854

Quoted 2 lines

tools/testing/selftests/kvm/lib/x86/processor.c +1 -1

-struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
+gva_t kvm_allocate_vcpu_stack(struct kvm_vm *vm)

Besides what Sashiko pointed out[1], this patch was just messed up during the rebase and it even doesn't compile.

[1] https://lore.kernel.org/all/[email protected]/

Quoted 39 lines

tools/testing/selftests/kvm/lib/x86/processor.c +21 -2

 {
 	struct kvm_mp_state mp_state;
 	struct kvm_regs regs;
+	gva_t stack_gva;
 	struct kvm_vcpu *vcpu;
 
+	stack_gva = __vm_alloc(vm, DEFAULT_STACK_PGS * getpagesize(),
+			       DEFAULT_GUEST_STACK_VADDR_MIN, MEM_REGION_DATA);
+
+	stack_gva += DEFAULT_STACK_PGS * getpagesize();
+
+	/*
+	 * Align stack to match calling sequence requirements in section "The
+	 * Stack Frame" of the System V ABI AMD64 Architecture Processor
+	 * Supplement, which requires the value (%rsp + 8) to be a multiple of
+	 * 16 when control is transferred to the function entry point.
+	 *
+	 * If this code is ever used to launch a vCPU with 32-bit entry point it
+	 * may need to subtract 4 bytes instead of 8 bytes.
+	 */
+	TEST_ASSERT(IS_ALIGNED(stack_gva, PAGE_SIZE),
+		    "__vm_alloc() did not provide a page-aligned address");
+	stack_gva -= 8;
+
 	vcpu = __vm_vcpu_add(vm, vcpu_id);
 	vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
 	vcpu_init_sregs(vm, vcpu);

@@ -864,8 +883,8 @@ struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
 
 	/* Setup guest general purpose registers */
 	vcpu_regs_get(vcpu, &regs);
-	regs.rflags = regs.rflags | X86_EFLAGS_FIXED;
-	regs.rsp = vm_alloc_stack(vm, DEFAULT_STACK_PGS);
+	regs.rflags = regs.rflags | 0x2;
+	regs.rsp = kvm_allocate_vcpu_stack(vm);
 	vcpu_regs_set(vcpu, &regs);
 
 	/* Setup the MP state */

Quoted 6 lines

tools/testing/selftests/kvm/lib/x86/processor.c void vcpu_arch_set_entry_point(struct kvm_vcpu *vcpu, void *guest_code) · line 854

Quoted 3 lines

tools/testing/selftests/kvm/lib/x86/processor.c +1 -1

-struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
+gva_t kvm_allocate_vcpu_stack(struct kvm_vm *vm)

Besides what Sashiko pointed out[1], this patch was just messed up during the rebase and it even doesn't compile.

Yes.

And since the upstream code already has vm_alloc_stack(), which basically does the same thing.

I think this patch can be dropped.

Quoted 2 lines

[1] https://lore.kernel.org/all/[email protected]/

tools/testing/selftests/kvm/lib/x86/processor.c +20 -8

 	vcpu = __vm_vcpu_add(vm, vcpu_id);
-	vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
-	vcpu_init_sregs(vm, vcpu);
-	vcpu_init_xcrs(vm, vcpu);
 
-	/* Setup guest general purpose registers */
-	vcpu_regs_get(vcpu, &regs);
-	regs.rflags = regs.rflags | 0x2;
-	regs.rsp = kvm_allocate_vcpu_stack(vm);
-	vcpu_regs_set(vcpu, &regs);
+	/*
+	 * Both kvm_get_supported_cpuid() (for legacy VMs) and KVM_TDX_GET_CPUID
+	 * (for TDX VMs) return VM-scoped CPUID. e.g. the APIC ID isn't
+	 * populated per vCPU. This is fine because KVM selftests don't
+	 * currently test CPUID topology enumeration.
+	 */
+	if (is_tdx_vm(vm)) {
+		tdx_vcpu_init(vm, vcpu);
+	} else {
+		vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
+
+		vcpu_init_sregs(vm, vcpu);
+		vcpu_init_xcrs(vm, vcpu);
+
+		/* Setup guest general purpose registers */
+		vcpu_regs_get(vcpu, &regs);
+		regs.rflags = regs.rflags | 0x2;
+		regs.rsp = kvm_allocate_vcpu_stack(vm);
+		vcpu_regs_set(vcpu, &regs);
+	}
 
 	/* Setup the MP state */
 	mp_state.mp_state = 0;

From: Sagi Shahar <[email protected]>

TDX VMs need to issue the KVM_TDX_INIT_VCPU ioctl for each vcpu after vcpu creation.

KVM_TDX_INIT_VCPU has a strict prerequisite for the CPUID state. To satisfy this requirement, call KVM_TDX_GET_CPUID and KVM_SET_CPUID2 to pull the CPUID configuration from the TDCS and commit it into KVM, allowing KVM_TDX_INIT_VCPU to succeed.

Additionally, unlike tdx_vm_ioctl(), tdx_vcpu_ioctl() doesn't check hw_error. KVM's vCPU-scoped TDX ioctl handlers don't propagate SEAMCALL errors into hw_error: the error is handled in the kernel and only an errno is returned. Checking the ioctl's return value and errno is therefore sufficient.

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

---
 .../selftests/kvm/include/x86/tdx/tdx_util.h       | 20 +++++++++
 tools/testing/selftests/kvm/lib/x86/processor.c    | 48 ++++++++++++++++++----
 2 files changed, 60 insertions(+), 8 deletions(-)

tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h +10 -0

index e529c587aeae..f5b2f32f2118 100644
@@ -46,6 +46,26 @@ static inline bool is_tdx_vm(struct kvm_vm *vm)
 		    (unsigned long long)hw_error);			\
 })
 
+#define __tdx_vcpu_ioctl(vcpu, cmd, _flags, arg)			\
+({									\
+	union {								\
+		struct kvm_tdx_cmd c;					\
+		unsigned long raw;					\
+	} tdx_cmd = { .c = {						\
+		.id = (cmd),						\
+		.flags = (u32)(_flags),					\
+		.data = (u64)(arg),					\
+	} };								\

tools/testing/selftests/kvm/include/x86/tdx/tdx_util.h +0 -0

 void tdx_init_vm(struct kvm_vm *vm);
 void tdx_vm_setup_boot_code_region(struct kvm_vm *vm);
 void tdx_vm_setup_boot_parameters_region(struct kvm_vm *vm, u32 nr_runnable_vcpus);

tools/testing/selftests/kvm/lib/x86/processor.c +3 -0

index 4a753fb43007..4af9cbf3fabb 100644
@@ -876,16 +876,48 @@ gva_t kvm_allocate_vcpu_stack(struct kvm_vm *vm)
 		    "__vm_alloc() did not provide a page-aligned address");
 	stack_gva -= 8;
 
+	return stack_gva;
+}
+

tools/testing/selftests/kvm/lib/x86/processor.c +27 -8

+
+struct kvm_vcpu *vm_arch_vcpu_add(struct kvm_vm *vm, u32 vcpu_id)
+{
+	struct kvm_mp_state mp_state;
+	struct kvm_vcpu *vcpu;
+	struct kvm_regs regs;
+
 	vcpu = __vm_vcpu_add(vm, vcpu_id);
-	vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
-	vcpu_init_sregs(vm, vcpu);
-	vcpu_init_xcrs(vm, vcpu);
 
-	/* Setup guest general purpose registers */
-	vcpu_regs_get(vcpu, &regs);
-	regs.rflags = regs.rflags | 0x2;
-	regs.rsp = kvm_allocate_vcpu_stack(vm);
-	vcpu_regs_set(vcpu, &regs);
+	/*
+	 * Both kvm_get_supported_cpuid() (for legacy VMs) and KVM_TDX_GET_CPUID
+	 * (for TDX VMs) return VM-scoped CPUID. e.g. the APIC ID isn't
+	 * populated per vCPU. This is fine because KVM selftests don't
+	 * currently test CPUID topology enumeration.
+	 */
+	if (is_tdx_vm(vm)) {
+		tdx_vcpu_init(vm, vcpu);
+	} else {
+		vcpu_init_cpuid(vcpu, kvm_get_supported_cpuid());
+
+		vcpu_init_sregs(vm, vcpu);
+		vcpu_init_xcrs(vm, vcpu);
+
+		/* Setup guest general purpose registers */
+		vcpu_regs_get(vcpu, &regs);
+		regs.rflags = regs.rflags | 0x2;
+		regs.rsp = kvm_allocate_vcpu_stack(vm);
+		vcpu_regs_set(vcpu, &regs);
+	}
 
 	/* Setup the MP state */
 	mp_state.mp_state = 0;

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c void tdx_vm_load_common_boot_parameters(struct kvm_vm *vm) · line 98

Quoted 6 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +6 -0

+void tdx_vcpu_load_boot_parameters(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
+{
+	struct td_boot_parameters *params =
+		addr_gpa2hva(vm, TD_BOOT_PARAMETERS_GPA);
+	struct td_per_vcpu_parameters *vcpu_params =
+		&params->per_vcpu[vcpu->id];

[Severity: Medium]
Will this lead to an out-of-bounds array access in tdx_vcpu_load_boot_parameters() if a test uses a sparse vcpu->id?

The boot parameters region appears to allocate memory for exactly nr_runnable_vcpus instances of struct td_per_vcpu_parameters in tdx_vm_setup_boot_parameters_region():

size_t boot_params_size = sizeof(struct td_boot_parameters) +
nr_runnable_vcpus * sizeof(struct td_per_vcpu_parameters);

Since vcpu->id represents the KVM vCPU ID (which can be the APIC ID on x86) and can be larger than or equal to nr_runnable_vcpus, could this write beyond the allocated bounds and corrupt adjacent host memory and guest physical pages?

This could be triggered if a selftest creating a TDX VM specifies a sparse vcpu->id that is larger than or equal to the total number of runnable vCPUs passed to vm_create().

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c void tdx_vm_load_common_boot_parameters(struct kvm_vm *vm) · line 102

Quoted 4 lines

tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +4 -0

+
+	vcpu_params->esp_gva = kvm_allocate_vcpu_stack(vm);
+	TEST_ASSERT(vcpu_params->esp_gva < (1ULL << 32),
+		    "ESP GVA must be within 32-bit address space for 32-bit boot code");

[Severity: Medium]
Does this bounds check in tdx_vcpu_load_boot_parameters() actually work, or is the value silently truncated before the check?

Because kvm_allocate_vcpu_stack() returns a 64-bit gva_t, assigning it to vcpu_params->esp_gva truncates the value to 32 bits since esp_gva is declared as a u32.

The TEST_ASSERT then evaluates the already truncated 32-bit value against (1ULL << 32), which will always be true. Could this bypass the intended safety check and cause silent stack corruption and test failures instead of an explicit assertion failure?

This could be triggered if a selftest allocates enough memory such that the guest stack virtual address exceeds 4GB.

From: Ackerley Tng <[email protected]>

TDX protected memory needs to be measured and encrypted before it can be used by the guest. Traverse the VM's memory regions and initialize all the protected ranges by calling KVM_TDX_INIT_MEM_REGION.

Once all the memory is initialized, the VM can be finalized by calling KVM_TDX_FINALIZE_VM.

Co-developed-by Erdem Aktas <[email protected]>

Signed-off-by Erdem Aktas <[email protected]>

Co-developed-by Sagi Shahar <[email protected]>

Signed-off-by Sagi Shahar <[email protected]>

Co-developed-by Lisa Wang <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Signed-off-by Ackerley Tng <[email protected]>

Reviewed-by Binbin Wu <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

From: Sagi Shahar <[email protected]>

Finalize TDX VM after VM and VCPU creation and memory initialization.

To integrate TDX VM finalization seamlessly, the finalization is hooked into kvm_arch_vm_finalize_vcpus(). This approach avoids the need for every TDX selftest to manually finalize the VM. While it does prevent TDX selftests from customizing memory before it is locked, no current selftests require this.

In TDX, finalization is a mandatory step to make the TD runnable. It also finalizes the MRTD of the VM's initial memory and state, locking them in for future attestation and preventing any further modifications.

Signed-off-by Sagi Shahar <[email protected]>

Signed-off-by Lisa Wang <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

---
 tools/testing/selftests/kvm/lib/x86/processor.c | 6 ++++++
 1 file changed, 6 insertions(+)

tools/testing/selftests/kvm/lib/x86/processor.c +6 -0

index b4b76dc505ae..e1d0fd5ed1f6 100644
@@ -1536,6 +1536,12 @@ bool kvm_arch_has_default_irqchip(void)
 	return true;
 }
 
+void kvm_arch_vm_finalize_vcpus(struct kvm_vm *vm)
+{
+	if (is_tdx_vm(vm))
+		tdx_vm_finalize(vm);
+}
+
 void setup_smram(struct kvm_vm *vm, struct kvm_vcpu *vcpu, u64 smram_gpa,
 		 const void *smi_handler, size_t handler_size)
 {