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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADrL8HVEAUdg5eJrU+RveR1+s+9ArdO6wa7EntLQZMu_iwBm-w@mail.gmail.com>
Date: Wed, 10 Sep 2025 14:37:48 -0700
From: James Houghton <jthoughton@...gle.com>
To: "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 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?

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?

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