On Mon, 2025-07-07 at 17:14 -0700, Vishal Annapurve wrote: > > > > Some architectures, e.g. SNP and TDX, may effectively require zeroing on > > conversion, > > but that's essentially a property of the architecture, i.e. an arch/vendor > > specific > > detail. > > Conversion operation is a unique capability supported by guest_memfd > files so my intention of bringing up zeroing was to better understand > the need and clarify the role of guest_memfd in handling zeroing > during conversion. > > Not sure if I am misinterpreting you, but treating "zeroing during > conversion" as the responsibility of arch/vendor specific > implementation outside of guest_memfd sounds good to me. For TDX if we don't zero on conversion from private->shared we will be dependent on behavior of the CPU when reading memory with keyid 0, which was previously encrypted and has some protection bits set. I don't *think* the behavior is architectural. So it might be prudent to either make it so, or zero it in the kernel in order to not make non-architectual behavior into userspace ABI. Up the thread Vishal says we need to support operations that use in-place conversion (overloaded term now I think, btw). Why exactly is pKVM using private/shared conversion for this private data provisioning? Instead of a special provisioning operation like the others? (Xiaoyao's suggestion)
