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. 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. Filling MEMORY_FAULT_EXIT iff the memslot flag is set would also lead to a weird ABI and/or funky KVM code. E.g. if MEMORY_FAULT_EXIT is tied to the fast-only memslot flag, what's the defined behavior if the gfn=>hva translation fails? KVM hasn't actually tried to gup() anything. Obviously not the end of the world, but I'd prefer not to avoid introduce more odditites into KVM, however minor. > Requiring two levels of opt-in to have the intended outcome for a single > architecture seems nauseating from a userspace perspective. If we usurp -EFAULT, I don't think we'll actually need an opt-in for MEMORY_FAULT_EXIT. KVM will need to add a capability so that userspace can query KVM support, but the actual filling of of kvm_run could be done unconditionally. Even if we do end up making the behavior opt-in, I would expect them to be largely orthogonal in userspace. E.g. userspace would always enable MEMORY_FAULT_EXIT during startup, and then toggle the memslot flag during postcopy.
