On Tue, Aug 29, 2023 at 3:42 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Thu, Aug 24, 2023, Anish Moorthy wrote: > > On Tue, Jul 11, 2023 at 8:29 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > Well, that description is wrong for other reasons. As mentioned in my reply > > > (got snipped), the behavior is not tied to sleeping or waiting on I/O. > > > > > > > Moving the nowait check out of __kvm_faultin_pfn()/user_mem_abort() > > > > and into __gfn_to_pfn_memslot() means that, obviously, other callers > > > > will start to see behavior changes. Some of that is probably actually > > > > necessary for that documentation to be accurate (since any usages of > > > > __gfn_to_pfn_memslot() under KVM_RUN should respect the memslot flag), > > > > but I think there are consumers of __gfn_to_pfn_memslot() from outside > > > > KVM_RUN. > > > > > > Yeah, replace "in response to page faults" with something along the lines of "if > > > an access in guest context ..." > > > > Alright, how about > > > > + KVM_MEM_NO_USERFAULT_ON_GUEST_ACCESS > > + The presence of this capability indicates that userspace may pass the > > + KVM_MEM_NO_USERFAULT_ON_GUEST_ACCESS flag to > > + KVM_SET_USER_MEMORY_REGION. Said flag will cause KVM_RUN to fail (-EFAULT) > > + in response to guest-context memory accesses which would require KVM > > + to page fault on the userspace mapping. > > > > Although, as Wang mentioned, USERFAULT seems to suggest something > > related to userfaultfd which is a liiiiitle too specific. Perhaps we > > should use USERSPACE_FAULT (*cries*) instead? > > Heh, it's not strictly on guest accesses though. Is the inaccuracy just because of the KVM_DEV_ARM_VGIC_GRP_CTRL disclaimer, or something else? I thought that "guest-context accesses" would capture the flag affecting memory accesses that KVM emulates for the guest as well, in addition to the "normal" EPT-violation -> page fault path. But if that's still not totally accurate then you should probably just spell this out for me. > At this point, I'm tempted to come up with some completely arbitrary name for the > feature and give up on trying to describe its effects in the name itself. You know, Oliver may have made an inspired suggestion a while back... On Mon, Mar 20, 2023 at 3:22 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > I couldn't care less about what the user-facing portion of this thing is > called, TBH. We could just refer to it as KVM_MEM_BIT_2 /s > > On Wed, Jun 14, 2023 at 2:20 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > We'll need a way to way for KVM to opt-out for kvm_vcpu_map(), at which point it > makes sense to opt-out for kvm_vm_ioctl_mte_copy_tags() as well. Uh oh, I sense another parameter to __gfn_to_pfn_memslot(). Although I did see that David Stevens has been proposing cleanups to that code [1]. Is proper practice here to take a dependency on his series, do we just resolve the conflicts when the series are merged, or something else? [1] https://lore.kernel.org/kvm/20230824080408.2933205-1-stevensd@xxxxxxxxxx/ > > 3. I don't think I've caught parts of the who-calls tree that are in > > drivers/. The one part I know about is the gfn_to_pfn() call in > > is_2MB_gtt_possible() (drivers/gpu/drm/i915/gvt/gtt.c), and I'm not > > sure what to do about it. Again, doesn't look like a guest-context > > access. > > On x86, that _was_ the only one. You're welcome ;-) > > https://lore.kernel.org/all/20230729013535.1070024-9-seanjc@xxxxxxxxxx Much obliged :D
