On Thu, Jun 01, 2023, Oliver Upton wrote: > Anish, > > On Wed, Apr 12, 2023 at 09:35:05PM +0000, Anish Moorthy wrote: > > +7.35 KVM_CAP_ABSENT_MAPPING_FAULT > > +--------------------------------- > > + > > +:Architectures: None > > +:Returns: -EINVAL. > > + > > +The presence of this capability indicates that userspace may pass the > > +KVM_MEM_ABSENT_MAPPING_FAULT flag to KVM_SET_USER_MEMORY_REGION to cause KVM_RUN > > +to fail (-EFAULT) in response to page faults for which the userspace page tables > > +do not contain present mappings. Attempting to enable the capability directly > > +will fail. > > + > > +The range of guest physical memory causing the fault is advertised to userspace > > +through KVM_CAP_MEMORY_FAULT_INFO (if it is enabled). > > Maybe third time is the charm. I *really* do not like the > interdependence between NOWAIT exits and the completely orthogonal > annotation of existing EFAULT exits. They're not completely orthogonal, because the touchpoints for NOWAIT are themselves existing EFAULT exits. > How do we support a userspace that only cares about NOWAIT exits but > doesn't want other EFAULT exits to be annotated? We don't. The proposed approach is to not change the return value, and the vcpu->run union currently holds random garbage on -EFAULT, so I don't see any reason to require userspace to opt-in, or to let userspace opt-out. I.e. fill vcpu->run->memory_fault unconditionally (for the paths that are converted) and advertise to userspace that vcpu->run->memory_fault *may* contain useful info on -EFAULT when KVM_CAP_MEMORY_FAULT_INFO is supported. And then we define KVM's ABI such that vcpu->run->memory_fault is guarateed to be valid if an -EFAULT occurs when faulting in guest memory (on supported architectures). > It is very likely that userspace will only know how to resolve NOWAIT exits > anyway. Since we do not provide a precise description of the conditions that > caused an exit, there's no way for userspace to differentiate between NOWAIT > exits and other exits it couldn't care less about. > > NOWAIT exits w/o annotation (i.e. a 'bare' EFAULT) make even less sense > since userspace cannot even tell what address needs fixing at that > point. > > This is why I had been suggesting we separate the two capabilities and > make annotated exits an unconditional property of NOWAIT exits. No, because as I've been stating ad nauseum, KVM cannot differentiate between a NOWAIT -EFAULT and an -EFAULT that would have occurred regardless of the NOWAIT behavior. Defining the ABI to be that KVM fills memory_fault if and only if the slot has NOWAIT will create a mess, e.g. if an -EFAULT occurs while userspace is doing a KVM_SET_USER_MEMORY_REGION to set NOWAIT, userspace may or may not see valid memory_fault information depending on when the vCPU grabbed its memslot snapshot.
