Re: [RFC PATCH 3/5] MAINTAINERS: Add an entry for KVM's guest_memfd

[Sean Christopherson <seanjc@google.com>]

On Thu, Apr 30, 2026, Ackerley Tng wrote:
> Sean Christopherson <seanjc@google.com> writes:
> 
> > To better reflect how guest_memfd has been maintained for the last few
> > years, and to prepare for significant upcoming growth and expansion, add a
> > dedicated MAINTAINERS entry for KVM's guest_memfd, with Paolo and myself
> > (Sean) as co-maintainers.
> >
> > List both the KVM and KVM x86 git trees as authoritative repositories, as
> > any given guest_memfd change has a equal odds of hitting KVM x86 or not.
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  MAINTAINERS | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 89b470db22de..9eceeb6f699d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14396,6 +14396,15 @@ S:	Maintained
> >  F:	Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
> >  F:	drivers/video/backlight/ktz8866.c
> >
> > +KVM GUEST_MEMFD
> > +M:	Sean Christopherson <seanjc@google.com>
> > +M:	Paolo Bonzini <pbonzini@redhat.com>
> > +L:	kvm@vger.kernel.org
> > +S:	Supported
> > +T:	git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> > +T:	git https://github.com/kvm-x86/linux.git
> > +F:	virt/kvm/guest_memfd.*
> 
> Should selftests for guest_memfd be added here too?

Hmm, no?  I don't think I want to go to that level of granularity for selftests,
at least not at this time.  Maybe if we end up with a large collection of
guest_memfd specific, arch-agnostic tests, then we could extend the entry?  But
even then, I don't think I want to go that route.

Much of the guest_memfd functionality and testing is in common files and/or
arch-specific code, e.g. a lot of the truly core functionality is in lib/kvm_util.c,
and set_memory_region_test.c and x86/private_mem_conversions_test.c have about as
much guest_memfd testing as guest_memfd_test.c.  I worry that adding a selftests
clause to KVM GUEST_MEMFD would do more harm than good, e.g. create expectations
that guest_memfd testing should be isolated and/or be reviewed differently or
something, without actually making it easier to maintain the tests.