On Wed, Nov 01, 2023, Anish Moorthy wrote: > On Wed, Nov 1, 2023 at 3:03 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Wed, Nov 01, 2023, Anish Moorthy wrote: > > > On Wed, Oct 4, 2023 at 6:44 PM Sean Christopherson <seanjc@xxxxxxxxxx> 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)
