quoted
Previously, without in-place conversion, populate never reads memory
from guest_memfd so there was no danger of leaking uninitialized memory.
quoted
In case post-populate failed, do we want to re-zero the pages?
I believe we can't re-zero the pages. When SNP fails to populate it
could be because SNP didn't like the CPUIDs userspace set up, and after
the error userspace is expected to check what SNP likes, then
retry.
Ah, okay.
quoted
IIUC zeroing will destroy the message SNP wanted to leave for userspace.
Michael should be able to explain more here :)
Not Michael, but the above is correct. If firmware rejects a CPUID page, then
KVM copies back the expected CPUID values provided by firmware.
That said, now that we have have @may_writeback_src we _could_ re-zero the page,
i.e. only zero pages for which @may_writeback_src is %false.
And _that_ said, I vote "no". KVM zeros the memory mostly to ensure userspace
can't read stale data, e.g. someone else's data. I don't think we need to
guarantee that a failed populate() (or rather, whatever ioctl called into it)
will leave memory in any particular state. It would be easier to document that
the page contents may be modified on failure.
Let's do that then!
--
Cheers,
David