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

On Wed, Aug 26, 2026, Michael Roth wrote:

On Wed, Aug 26, 2026 at 03:33:43PM -0700, Sean Christopherson wrote:

quoted

quoted

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.

quoted

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).