Re: [PATCH v11 15/46] KVM: guest_memfd: Call arch make_shared callback for to-shared conversion

[Sean Christopherson]

On Wed, Aug 26, 2026, Michael Roth wrote:
> On Wed, Aug 26, 2026 at 03:33:43PM -0700, Sean Christopherson wrote:
> > > So there's real performance differences here but it's sort of been
> > > addressed through a solution that offers additional performance
> > > benefits on top so there's no longer as much to be gained here I think.
> > 
> > Or another way to look at it, eager conversion would allow QEMU to drop its
> > workaround.
> 
> True, for SNP at least, but pre-map is nice too, and not really gmem's
> place, so most likely KVM_PRE_FAULT_MEMORY would remain regardless.

Hmm, good point.  And as below, we can't sanely avoid the check in kvm_gmem_get_pfn()
without reintroducing the preparation tracking, so the lazy approach is probably
the best option at this point.

> > To be clear, I'm a-ok with the code as-is, I just want to make sure we document
> > exactly why we're choosing this implementation.
> 
> Agreed. My understanding of the current design choice is basically that
> it doesn't *need* to happen here, since kvm_gmem_get_pfn() will already
> trigger it on-demand when it is actually needed (or not), and that tends
> to happen at fault time when other platforms like TDX handle it. 

Oh, this jogged my memory.  For out-of-place conversion, waiting until
kvm_gmem_get_pfn() to update the RMP makes sense because KVM doesn't know whether
or not the SHARED backing as been allocated, and can't easily get at it in the
first place.

> To handle it differently would be to go out of our way to make SNP special in
> this flow in exchange for performance, 

Not really?  We'd still need kvm_gmem_get_pfn() to update the RMP to handle PFNs
that were never explicitly converted.  Either that or KVM would have to preallocate
everything (ewww).