On Thu, Jun 15, 2023, Wei W Wang wrote: > On Thursday, June 15, 2023 5:21 AM, Sean Christopherson wrote: > > Ah, crud. The above highlights something I missed in v3. The memslot NOWAIT > > flag isn't tied to FOLL_NOWAIT, it's really truly a "fast-only" flag. And even > > more confusingly, KVM does set FOLL_NOWAIT, but for the async #PF case, > > which will get even more confusing if/when KVM uses FOLL_NOWAIT internally. > > > > Drat. I really like the NOWAIT name, but unfortunately it doesn't do what as the > > name says. > > > > I still don't love "fast-only" as that bleeds kernel internals to userspace. > > Anyone have ideas? Maybe something about not installing new mappings? > > Yes, "NOWAIT" sounds a bit confusing here. If this is a patch applied to userfaultfd > to solve the "wait" issue on queuing/handling faults, then it would make sense. > But this is a KVM specific solution, which is not directly related to userfaultfd, and > it's not related to FOLL_NOWAIT. There seems nothing to wait in the KVM context > here. > > Why not just name the cap as what it does (i.e. something to indicate the cap of > having the fault exited to userspace to handle), e.g. KVM_CAP_EXIT_ON_FAULT > or KVM_CAP_USERSPACE_FAULT. Because that's even further away from the truth when accounting for the fact that the flag controls behavior when handling are *guest* faults. The memslot flag doesn't cause KVM to exit on every guest fault. And USERSPACE_FAULT is far too vague; KVM constantly faults in userspace mappings, the flag needs to communicate that KVM *won't* do that for guest accesses. Something like KVM_MEM_NO_USERFAULT_ON_GUEST_ACCESS? Ridiculously verbose, but I think it captures the KVM behavior, and "guest access" instead of "guest fault" gives KVM some wiggle room, e.g. the name won't become stale if we figure out a way to apply the behavior to KVM emulation of guest accesses in the future.
