Re: [PATCH v5 0/2] KVM: guest_memfd: use write for population

[Nikita Kalyazin <kalyazin@amazon.com>]

On 10/09/2025 22:37, James Houghton wrote:
> On Tue, Sep 2, 2025 at 4:20 AM Kalyazin, Nikita <kalyazin@amazon.co.uk> wrote:
>>
>> [ based on kvm/next ]
>>
>> Implement guest_memfd allocation and population via the write syscall.
>> This is useful in non-CoCo use cases where the host can access guest
>> memory.  Even though the same can also be achieved via userspace mapping
>> and memcpying from userspace, write provides a more performant option
>> because it does not need to set page tables and it does not cause a page
>> fault for every page like memcpy would.  Note that memcpy cannot be
>> accelerated via MADV_POPULATE_WRITE as it is  not supported by
>> guest_memfd and relies on GUP.
>>
>> Populating 512MiB of guest_memfd on a x86 machine:
>>   - via memcpy: 436 ms
>>   - via write:  202 ms (-54%)
> 
> Silly question: can you remind me why this speed-up is important?

The speed-up is important for the Firecracker use case [1] because it is 
likely for the population to stand on the hot path of the snapshot 
restore process.  Even though we aim to prepopulate the guest memory 
before it gets accessed by the guest, for large VMs the guest has a good 
chance to hit a page that isn't yet populated triggering on-demand fault 
handling which is much slower, and we'd like to avoid those as much as 
we can.

[1]: 
https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/handling-page-faults-on-snapshot-resume.md


> 
> Also, I think we can get the same effect as MADV_POPULATE_WRITE just
> by making a second VMA for the memory file and reading the first byte
> of each page. Is that a viable strategy for your use case?

If I understand correctly what you mean, it doesn't look much different 
from the memcpy option I mention above.  All those one-byte read 
accesses will trigger user mapping faults for every page, and they are 
quite slow.  write() allows to avoid them completely.


> 
> Seems fine to me to allow write() for guest_memfd anyway. :)

Glad to hear that!