On Tue, Jun 23, 2026 at 01:16:14PM +0800, Yan Zhao wrote: > On Mon, Jun 22, 2026 at 06:22:45PM -0700, Sean Christopherson wrote: > > On Mon, Jun 22, 2026, Yan Zhao wrote: > > > On Thu, Jun 18, 2026 at 05:32:00PM -0700, Ackerley Tng via B4 Relay wrote: > > > > From: Ackerley Tng <[email protected]> > > > > > > > > Update tdx_gmem_post_populate() to handle cases where a source page is > > > > not explicitly provided. Instead of returning -EOPNOTSUPP when src_page > > > > is NULL, default to using the page associated with the destination PFN. > > > > > > > > This change allows for in-place memory conversion where the data is > > > > already present in the target PFN, ensuring the TDX module has a valid > > > > source page reference for the TDH.MEM.PAGE.ADD operation. > > > > > > > > Signed-off-by: Ackerley Tng <[email protected]> > > > > Signed-off-by: Sean Christopherson <[email protected]> > > > > --- > > > > Documentation/virt/kvm/x86/intel-tdx.rst | 4 ++++ > > > > arch/x86/kvm/vmx/tdx.c | 11 ++++++++--- > > > > 2 files changed, 12 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/Documentation/virt/kvm/x86/intel-tdx.rst > > > > b/Documentation/virt/kvm/x86/intel-tdx.rst > > > > index 6a222e9d09541..74357fe87f9ec 100644 > > > > --- a/Documentation/virt/kvm/x86/intel-tdx.rst > > > > +++ b/Documentation/virt/kvm/x86/intel-tdx.rst > > > > @@ -158,6 +158,10 @@ KVM_TDX_INIT_MEM_REGION > > > > Initialize @nr_pages TDX guest private memory starting from @gpa with > > > > userspace > > > > provided data from @source_addr. @source_addr must be > > > > PAGE_SIZE-aligned. > > > > > > > > +If guest_memfd in-place conversion is enabled, pass NULL for > > > > @source_addr to > > > > +initialize the memory region using memory contents already populated in > > > > +guest_memfd memory. > > > > + > > > > Note, before calling this sub command, memory attribute of the range > > > > [gpa, gpa + nr_pages] needs to be private. Userspace can use > > > > KVM_SET_MEMORY_ATTRIBUTES to set the attribute. > > > > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c > > > > index ffe9d0db58c59..56d10333c61a7 100644 > > > > --- a/arch/x86/kvm/vmx/tdx.c > > > > +++ b/arch/x86/kvm/vmx/tdx.c > > > > @@ -3198,8 +3198,12 @@ static int tdx_gmem_post_populate(struct kvm > > > > *kvm, gfn_t gfn, kvm_pfn_t pfn, > > > > if (KVM_BUG_ON(kvm_tdx->page_add_src, kvm)) > > > > return -EIO; > > > > > > > > - if (!src_page) > > > > - return -EOPNOTSUPP; > > > > + if (!src_page) { > > > > + if (!gmem_in_place_conversion) > > > When userspace turns on gmem_in_place_conversion while creating > > > guest_memfd > > > without the MMAP flag, the absence of src_page should still be treated as > > > an > > > error. > > > > Why MMAP? > Hmm, I was showing a scenario that in-place conversion couldn't occur. > I didn't mean that with the MMAP flag, mmap() and user write must occur. > > > Shouldn't this be a general "if (!src_page && !up-to-date)"? Just > > because userspace _can_ mmap() the memory doesn't mean userspace _has_ > > mmap()'d > > and written memory. And when write() lands, MMAP wouldn't be necessary to > > initialize the memory. > Do you mean using up-to-date flag as below? > > if (!src_page) { > src_page = pfn_to_page(pfn); > if (!folio_test_uptodate(page_folio(src_page))) > return -EOPNOTSUPP; > }
Another concern with this fix is that: commit "KVM: guest_memfd: Zero page while getting pfn" [1] always marks the folio uptodate before reaching post_populate(). [1] https://lore.kernel.org/all/[email protected]/ > One concern is that TDX now does not much care about the up-to-date flag since > TDX doesn't rely on the flag to clear pages on conversions. > I'm not sure if the flag can be reliably checked in this case. e.g., > now the whole folio is marked up-to-date even if only part of it is faulted by > user access. > Ensuring that the up-to-date flag works correctly with huge page support seems > to have more effort than introducing a dedicated flag for TDX. > > > > Additionally, to properly enable in-place copying for the TDX initial > > > memory > > > region, userspace must not only specify source_addr to NULL, but also > > > follow > > > a specific sequence (where steps 1/2/3/7 are required only for in-place > > > copy): > > > 1. create guest_memfd with MMAP flag > > > 2. mmap the guest_memfd. > > > 3. convert the initial memory range to shared. > > > 4. copy initial content to the source page. > > > 5. convert the initial memory range to private > > > 6. invoke ioctl KVM_TDX_INIT_MEM_REGION. > > > 7. do not unmap the source backend. > > > > > > So, would it be reasonable to introduce a dedicated flag that allows > > > userspace > > > to explicitly opt into the in-place copy functionality? e.g., > > > > Why? It's userspace's responsibility to get the above right. If userspace > > fails > > to provide a src_page when it doesn't want in-place copy, that's a > > userspace bug. > I mean if userspace specifies a NULL source_addr by mistake, it's better for > kernel to detect this mistake, similar to how it validates whether source_addr > is PAGE_ALIGNED. > Since userspace already needs to perform additional steps to enable in-place > copy, specifying a dedicated flag to indicate that the NULL source_addr is > intentional seems like a reasonable burden.
