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. How do we support a userspace that only cares about NOWAIT exits but doesn't want other EFAULT exits to be annotated? 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. It aligns with the practical use you're proposing for the series, and still puts userspace in the drivers seat for other issues it may or may not care about. -- Thanks, Oliver
