On Fri, Mar 17, 2023, Anish Moorthy wrote: > 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/ Strictly speaking, if y'all buy my argument that the flag shouldn't control the gup behavior, there won't be semantic differences for the memslot flag. KVM will (obviously) behavior differently if KVM_CAP_MEMORY_FAULT_EXIT is not set, but that will hold true for x86 as well. The only difference is that x86 will also support an orthogonal flag that makes the fast-only memslot flag useful in practice. So yeah, there will be an arch dependency, but only because arch code needs to actually handle perform the exit, and that's true no matter what. That said, there's zero reason to put X86 in the name. Just add the capability as KVM_CAP_MEMORY_FAULT_EXIT or whatever and mark it as x86 in the documentation.
