Re: [PATCH 2/2] KVM: selftests: Test KVM_PRE_FAULT_MEMORY against a full dirty ring

[Sean Christopherson <seanjc@google.com>]

On Wed, Nov 11, 2026, Alexandru Elisei wrote:
> On Tue, Nov 10, 2026 at 04:02:21PM +0000, Lorenzo Stoakes (ARM) wrote:
> > On Tue, Nov 10, 2026 at 07:53:35AM -0800, Sean Christopherson wrote:
> > > On Tue, Nov 10, 2026, Fuad Tabba wrote:
> > > > > > diff --git a/tools/testing/selftests/kvm/pre_fault_memory_test.c b/tools/testing/selftests/kvm/pre_fault_memory_test.c
> > > > [...]
> > > > > > +static void test_pre_fault_dirty_ring(void)
> > > > [...]
> > > > > > +    /* Populate the pages, so that pre-faulting can map them writable. */
> > > > >
> > > > > Reviewed below, but I wonder how x86 could then read fault these?
> > > >
> > > > KVM_PRE_FAULT_MEMORY is defined as a read fault, but x86 maps the page
> > > > writable when the host page is, and marks it dirty, unless it falls
> > > > back to access tracking (below). Populating the pages makes sure they
> > > > aren't backed by the zero page.
> > >
> > > Before we effectively solidify the behavior, I think we should have an explicit
> > > discussion about the desired behavior of KVM_PRE_FAULT_MEMORY when dirty logging
> > > is enabled.  E.g. the only reason I kept the existing behavior in my auto-prefault
> > > series was because I couldn't think of a good reason to change it.  But we never
> > > made a concious decision in the first place, i.e. we never considered what would
> > > happen if prefaulting collided with dirty logging (as evidenced by this bug).
> > 
> > Yeah, I do worry about implicit assumptions (also commented re: ordering).
> > 
> > I guess what makes sense, given the general approach for prefaulting = injecting
> > a synthetic read fault, is for the expectation to be that it matches the
> > behaviour of an ordinary read fault.
> 
> Unfortunately, what happens in this case is not as obvious as it sounds,
> because a read fault on a memslot backed by guest_memfd maps the GPA with
> read *and* write permission on arm64 (if the memslot is not readonly,
> haven't checked what x86 does).

Ya, this isn't about read vs. write faults, it's about whether or not *any* "fault"
from KVM_PRE_FAULT_MEMORY should be allowed if the target memslot has dirty logging
enabled.

I'm leaning toward "yes", mainly because I suspect that fully preventing installing
writable mappings when dirty logging is enabled across all architectures would be
more difficult that ensuring generic code doesn't explode, and in practice I doubt
any real VMM usage of KVM_PRE_FAULT_MEMORY will care about dirty logging interactions,
i.e. any KVM behavior will be a-ok with userspace.