On Tue, Jul 08, 2025, Vishal Annapurve wrote: > On Tue, Jul 8, 2025 at 11:03 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > Few points that seem important here: > 1) Userspace can and should be able to only dictate if memory contents > need to be preserved on shared to private conversion. No, I was wrong, pKVM has use cases where it's desirable to preserve data on private => shared conversions. Side topic, if you're going to use fancy indentation, align the indentation so it's actually readable. > -> For SNP/TDX VMs: > * Only usecase for preserving contents is initial memory > population, which can be achieved by: > - Userspace converting the ranges to shared, populating the contents, > converting them back to private and then calling SNP/TDX specific > existing ABI functions. > * For runtime conversions, guest_memfd can't ensure memory contents are > preserved during shared to private conversions as the architectures > don't support that behavior. > * So IMO, this "preserve" flag doesn't make sense for SNP/TDX VMs, even It makes sense, it's just not supported by the architecture *at runtime*. Case in point, *something* needs to allow preserving data prior to launching the VM. If we want to go with the PRIVATE => SHARED => FILL => PRIVATE approach for TDX and SNP, then we'll probably want to allow PRESERVE only until the VM image is finalized. > if we add this flag, today guest_memfd should effectively mark this > unsupported based on the backing architecture support. > > 2) For pKVM, if userspace wants to specify a "preserve" flag then this There is no "For pKVM". We are defining uAPI for guest_memfd. I.e. this statement holds true for all implementations: PRESERVE is allowed based on the capabilities of the architecture. > So this topic is still orthogonal to "zeroing on private to shared conversion". As above, no. pKVM might not expose PRESERVE to _userspace_ since all current conversions are initiated by the guest, but for guest_memfd itself, this is all one and the same.
