Re: [PATCH v12 19/45] KVM: guest_memfd: Zero page while getting pfn

From: David Hildenbrand (Arm)

Date: Wed Sep 09 2026 - 14:09:15 EST


On 8/31/26 02:25, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@xxxxxxxxxx>
>
> Move the folio initialization logic from kvm_gmem_get_pfn() into
> __kvm_gmem_get_pfn() to also zero pages if the page is to be used in
> kvm_gmem_populate().
>
> With in-place conversion, the existing data in a guest_memfd page can be
> populated into guest memory through platform-specific ioctls.
>
> Without first zeroing the page obtained using __kvm_gmem_get_pfn(), it
> might contain uninitialized host memory, which would leak to the guest if
> the populate completes.
>
> guest_memfd pages are zeroed at most once in the page's entire lifetime
> with guest_memfd, and that is tracked using the uptodate flag.
>
> Zeroing the page in __kvm_gmem_get_pfn() is chosen over zeroing in
> kvm_gmem_get_folio() since other flows, such as a future write() syscall,
> can get a page, write to the page and then set page uptodate without
> zeroing.
>
> There may be some performance penalty due to redundant zeroing, but this
> would pale in comparison to the cost of actually assigning the page to the
> VM.
>
> This aligns with the concept of zeroing before first use - the other place
> where zeroing happens is in kvm_gmem_fault_user_mapping().
>
> On populate failure, the page is not re-zeroed, since on SNP, if firmware
> rejects a CPUID page, the expected CPUID values provided by firmware are
> returned to userspace via page contents. More generally, page contents may
> be modified on populate failure.
>
> Don't mark the page uptodate again after populating, since the page would
> already be marked uptodate before the post_populate() call.
>
> Reviewed-by: Fuad Tabba <tabba@xxxxxxxxxx>
> Tested-by: Shivank Garg <shivankg@xxxxxxx>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
> Reviewed-by: Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx>
> Signed-off-by: Ackerley Tng <ackerleytng@xxxxxxxxxx>
> ---

Reviewed-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

--
Cheers,

David