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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ad56d448-4016-46d8-90ca-f0f17f7587c7@amazon.com>
Date: Thu, 11 Sep 2025 11:15:17 +0100
From: Nikita Kalyazin <kalyazin@...zon.com>
To: James Houghton <jthoughton@...gle.com>, "Kalyazin, Nikita"
	<kalyazin@...zon.co.uk>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "shuah@...nel.org"
	<shuah@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"michael.day@....com" <michael.day@....com>, "david@...hat.com"
	<david@...hat.com>, "Roy, Patrick" <roypat@...zon.co.uk>, "Thomson, Jack"
	<jackabt@...zon.co.uk>, "Manwaring, Derek" <derekmn@...zon.com>, "Cali,
 Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v5 0/2] KVM: guest_memfd: use write for population



On 10/09/2025 22:37, James Houghton wrote:
> On Tue, Sep 2, 2025 at 4:20 AM Kalyazin, Nikita <kalyazin@...zon.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!