On Fri, Oct 24, 2025 at 11:02 AM Sean Christopherson seanjc@google.com wrote:
On Thu, Oct 23, 2025, Sagi Shahar wrote:
On Wed, Oct 15, 2025 at 11:25 AM Ira Weiny ira.weiny@intel.com wrote:
Sagi Shahar wrote:
From: Ackerley Tng ackerleytng@google.com
[snip]
diff --git a/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c b/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c index 2551b3eac8f8..53cfadeff8de 100644 --- a/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c +++ b/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c @@ -270,3 +270,61 @@ void vm_tdx_init_vm(struct kvm_vm *vm, uint64_t attributes)
free(init_vm);}
[snip]
+void vm_tdx_finalize(struct kvm_vm *vm)
Why is this not a new kvm_arch_vm_finalize_vcpu() call?
What do you mean?
Ira is pointing out that upstream now has kvm_arch_vm_finalize_vcpus(), so you can (and I agree, should) implement that for x86.c, and do vm_tdx_finalize() from there (based on the VM shape) instead of requiring the caller to manually finalize the TD.
Unlike SEV, where userspace can manipulate guest state prior to LAUNCH, TDX guest state is unreachable from time zero, i.e. there is unlikely to be many (any?) use cases where a selftest wants to do something between creating vCPUs and finalizing the TD.
There are actually a few use cases for calling vm_tdx_finalize seperately from the create phase. One such case is when a user wants to add additional memslots for testing shared memory conversions. Another one is installing interrupt handlers. But these are probably rare enough that they can call __vm_create() and vm_vcpu_add() manually instead of using the wrapper