Yan Zhao wrote: > On Tue, Aug 26, 2025 at 05:05:19PM -0700, Sean Christopherson wrote: [snip] > > @@ -1641,14 +1618,30 @@ static int tdx_sept_set_private_spte(struct kvm *kvm, gfn_t gfn, > > return -EIO; > > > > /* > > - * Read 'pre_fault_allowed' before 'kvm_tdx->state'; see matching > > - * barrier in tdx_td_finalize(). > > + * Ensure pre_fault_allowed is read by kvm_arch_vcpu_pre_fault_memory() > > + * before kvm_tdx->state. Userspace must not be allowed to pre-fault > > + * arbitrary memory until the initial memory image is finalized. Pairs > > + * with the smp_wmb() in tdx_td_finalize(). > > */ > > smp_rmb(); > > - if (likely(kvm_tdx->state == TD_STATE_RUNNABLE)) > > - return tdx_mem_page_aug(kvm, gfn, level, pfn); > > > > - return tdx_mem_page_record_premap_cnt(kvm, gfn, level, pfn); > > + /* > > + * If the TD isn't finalized/runnable, then userspace is initializing > > + * the VM image via KVM_TDX_INIT_MEM_REGION. Increment the number of > > + * pages that need to be initialized via TDH.MEM.PAGE.ADD (PAGE.ADD > > + * requires a pre-existing S-EPT mapping). KVM_TDX_FINALIZE_VM checks > > + * the counter to ensure all mapped pages have been added to the image, > > + * to prevent running the TD with uninitialized memory. > To prevent the mismatch between mirror EPT and the S-EPT? > > e.g., Before KVM_TDX_FINALIZE_VM, > if userspace performs a zap after the TDH.MEM.PAGE.ADD, the page will be removed > from the S-EPT. The count of nr_premapped will not change after the successful > TDH.MEM.RANGE.BLOCK and TDH.MEM.PAGE.REMOVE. > > As a result, the TD will still run with uninitialized memory. I'm wondering if we are trying to over-architect this. Should we even allow KVM_TDX_FINALIZE_VM to race with KVM_TDX_INIT_MEM_REGION? What is the use case for that? It seems a basic sanity check/KVM_BUG_ON would suffice to tell the user; Don't start adding memory dynamically until yall have finalized the VM. Ira
