Re: [PATCH v5 10/17] KVM: Implement KVM_CAP_USERFAULT_ON_MISSING by atomizing __gfn_to_pfn_memslot() calls

[Sean Christopherson <seanjc@google.com>]

On Wed, Nov 01, 2023, Anish Moorthy wrote:
> On Wed, Nov 1, 2023 at 3:03 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Wed, Nov 01, 2023, Anish Moorthy wrote:
> > > On Wed, Oct 4, 2023 at 6:44 PM Sean Christopherson <seanjc@google.com> wrote:
> > > >
> > > > Eh, the shortlog basically says "do work" with a lot of fancy words.  It really
> > > > just boils down to:
> > > >
> > > >   KVM: Let callers of __gfn_to_pfn_memslot() opt-out of USERFAULT_ON_MISSING
> > >
> > > Proposed commit message for v6:
> > >
> > > > KVM: Implement KVM_CAP EXIT_ON_MISSING by checking memslot flag in __gfn_to_pfn_memslot()
> > > >
> > > > When the slot flag is enabled, forbid __gfn_to_pfn_memslot() from
> > > > faulting in pages for which mappings are absent. However, some callers of
> > > > __gfn_to_pfn_memslot() (such as kvm_vcpu_map()) must be able to opt out
> > > > of this behavior: allow doing so via the new can_exit_on_missing
> > > > parameter.
> > >
> > > Although separately, I don't think the parameter should be named
> > > can_exit_on_missing (or, as you suggested, can_do_userfault)-
> > > __gfn_to_pfn_memslot() shouldn't know or care how its callers are
> > > setting up KVM exits, after all.
> >
> > Why not?  __gfn_to_pfn_memslot() gets passed all kinds of constraints, I don't
> > see how "I can't handle exits to userspace" is any different.
> 
> Well the thing is that __gfn_to_pfn_memslot() is orthogonal to KVM
> exits. Its callers are just using it to try resolving a pfn, and what
> they do with the results is up to them.

But "how" the pfn is resolved is the business of the caller and of __gfn_to_pfn_memslot().
This already exits in the form of @async and @atomic, which respectively say
"don't wait on I/O" and "can't sleep, period".  The @async name is confusing,
but David Steven's series is planning on replacing that with the much more literal
FOLL_NOWAIT (IIRC).

> Put more concretely, __gfn_to_pfn_memslot() has many callers of which
> only two (the stage-2 fault handlers) actually use it to set up a KVM
> exit- how does a parameter named "can_exit_on_missing" make sense to
> its callers in general? 

It's a flag that says "I can't exit right now, please ignore exit_on_missing".

> If it were __gfn_to_pfn_memslot() itself that was populating the run struct
> in response to absent mappings then I would agree that the name was
> appropriate- but that's not what's going on here.
> 
> (side note, I'll assume that aside from the current naming discussion
> the commit message I proposed is fine)