On Fri, Oct 24, 2025 at 11:02 AM Sean Christopherson <[email protected]> wrote: > > On Thu, Oct 23, 2025, Sagi Shahar wrote: > > On Wed, Oct 15, 2025 at 11:25 AM Ira Weiny <[email protected]> wrote: > > > > > > Sagi Shahar wrote: > > > > From: Ackerley Tng <[email protected]> > > > > > > > > > > [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
