On Tue, Mar 21, 2023 at 07:50:35AM -0700, Sean Christopherson wrote: > On Mon, Mar 20, 2023, Oliver Upton wrote: > > On Fri, Mar 17, 2023 at 01:17:22PM -0700, Sean Christopherson wrote: > > > On Fri, Mar 17, 2023, Oliver Upton wrote: > > > > I'm not a fan of this architecture-specific dependency. Userspace is already > > > > explicitly opting in to this behavior by way of the memslot flag. These sort > > > > of exits are entirely orthogonal to the -EFAULT conversion earlier in the > > > > series. > > > > > > Ya, yet another reason not to speculate on why KVM wasn't able to resolve a fault. > > > > Regardless of what we name this memslot flag, we're already getting explicit > > opt-in from userspace for new behavior. There seems to be zero value in > > supporting memslot_flag && !MEMORY_FAULT_EXIT (i.e. returning EFAULT), > > so why even bother? > > Because there are use cases for MEMORY_FAULT_EXIT beyond fast-only gup. To be abundantly clear -- I have no issue with (nor care about) the other MEMORY_FAULT_EXIT changes. If we go the route of explicit user opt-in then that deserves its own distinct bit of UAPI. None of my objection pertains to the conversion of existing -EFAULT exits. > We could have the memslot feature depend on the MEMORY_FAULT_EXIT capability, > but I don't see how that adds value for either KVM or userspace. That is exactly what I want to avoid! My issue was the language here: +(*) NOTE: On x86, KVM_CAP_X86_MEMORY_FAULT_EXIT must be enabled for the +KVM_MEMFAULT_REASON_ABSENT_MAPPING_reason: otherwise userspace will only receive +a -EFAULT from KVM_RUN without any useful information. Which sounds to me as though there are *two* UAPI bits for the whole fast-gup failed interaction (flip a bit in the CAP and set a bit on the memslot, but only for x86). What I'm asking for is this: 1) A capability advertising MEMORY_FAULT_EXIT to userspace. Either usurp EFAULT or require userspace to enable this capability to convert _existing_ EFAULT exits to the new way of the world. 2) A capability and a single memslot flag to enable the fast-gup-only behavior (naming TBD). This does not depend on (1) in any way, i.e. only setting (2) should still result in MEMORY_FAULT_EXITs when fast gup fails. IOW, enabling (2) should always yield precise fault information to userspace. -- Thanks, Oliver
