Re: [RFC PATCH 0/3] KVM: Dirty page logging for guest_memfd-only memslots

[Alexandru Elisei <alexandru.elisei@arm.com>]

Hi Sean,

On Mon, Jul 06, 2026 at 05:56:12PM -0700, Sean Christopherson wrote:
> On Thu, Jul 02, 2026, Alexandru Elisei wrote:
> > The memory represented by guest_memfd-only memslots
> > (kvm_memslot_is_gmem_only() is true) is shared with userspace, which can
> > freely mmap it and access it. The only thing that is preventing dirty page
> > logging for such memslots is that KVM doesn't allow slots backed by
> > guest_memfd to have their flags changed; they can only be created and
> > deleted.
> 
> Please (publicly) document *why*  you want to add dirty-logging support.  It's
> all but impossible to review new uAPI without knowing the use case.

Of course, my mistake, I was so deep in this that I didn't realise that
there might be different perspectives.

My thinking was that since guest_memfd created with GUEST_MEMFD_FLAG_MMAP +
GUEST_MEMFD_FLAG_INIT_SHARED is extremely similar from a userspace point of
view to using an anonymous file (created with memfd_create()), that
supporting dirty page logging and migration would be a natural next step
and would expand the usefulness of guest_memfd. It has nothing to do with
confidential compute.

As to why I'm working on it now, it's because of an arm64 feature that
requires that memory remains mapped at stage 2, called Statistical
Profiling Extension (SPE), similar to Intel's PEBS or AMD's IBS. Exposing
the feature to a guest requires that memory remains mapped at stage 2
outside of userspace explicitely unmapping it, and guest_memfd, with the
patch to ignore the MMU notifiers [1], has this property.  I wanted to
expand the functionality of guest_memfd to support migration of virtual
machines when that arm64 feature is exposed to guests.

[1] https://lore.kernel.org/kvmarm/20260625130902.258331-1-alexandru.elisei@arm.com/

Thanks,
Alex