On Fri, Mar 17, 2023 at 11:59 AM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > + #define KVM_MEM_ABSENT_MAPPING_FAULT (1UL << 2) > > call it KVM_MEM_EXIT_ABSENT_MAPPING > ... > 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. I'm not a fan of the semantics varying between architectures either: but the reason I have it like that (and that the EFAULT conversions exist in this series in the first place) is (a) not having KVM_CAP_MEMORY_FAULT_EXIT implemented for arm and (b) Sean's following statement from https://lore.kernel.org/kvm/Y%2FfS0eab7GG0NVKS@xxxxxxxxxx/ On Thu, Feb 23, 2023 at 12:55 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > The new memslot flag should depend on KVM_CAP_MEMORY_FAULT_EXIT, but > KVM_CAP_MEMORY_FAULT_EXIT should be a standalone thing, i.e. should convert "all" > guest-memory -EFAULTS to KVM_CAP_MEMORY_FAULT_EXIT. All in quotes because I would > likely be ok with a partial conversion for the initial implementation if there > are paths that would require an absurd amount of work to convert. The best way that I thought of how to do that was to have one cap (KVM_CAP_MEMORY_FAULT_NOWAIT) to make KVM -EFAULT without calling slow GUP, and KVM_CAP_MEMORY_FAULT_EXIT to transform efaults to useful vm exits. But if you think the two are really orthogonal, then we need to resolve the apparent disagreement.
