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