On Wed, Feb 15, 2023 at 01:16:11AM +0000, Anish Moorthy wrote: > This new KVM exit allows userspace to handle missing memory. It > indicates that the pages in the range [gpa, gpa + size) must be mapped. > > The "flags" field actually goes unused in this series: it's included for > forward compatibility with [1], should this series happen to go in > first. > > [1] https://lore.kernel.org/all/CA+EHjTyzZ2n8kQxH_Qx72aRq1k+dETJXTsoOM3tggPZAZkYbCA@xxxxxxxxxxxxxx/ > > Signed-off-by: Anish Moorthy <amoorthy@xxxxxxxxxx> > Acked-by: James Houghton <jthoughton@xxxxxxxxxx> > --- > Documentation/virt/kvm/api.rst | 42 ++++++++++++++++++++++++++++++++++ > include/linux/kvm_host.h | 13 +++++++++++ > include/uapi/linux/kvm.h | 13 ++++++++++- > tools/include/uapi/linux/kvm.h | 7 ++++++ > virt/kvm/kvm_main.c | 26 +++++++++++++++++++++ > 5 files changed, 100 insertions(+), 1 deletion(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 9807b05a1b571..4b06e60668686 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -5937,6 +5937,18 @@ delivery must be provided via the "reg_aen" struct. > The "pad" and "reserved" fields may be used for future extensions and should be > set to 0s by userspace. > > +4.137 KVM_SET_MEM_FAULT_NOWAIT > +------------------------------ > + > +:Capability: KVM_CAP_MEM_FAULT_NOWAIT > +:Architectures: x86, arm64 > +:Type: vm ioctl > +:Parameters: bool state (in) > +:Returns: 0 on success, or -1 if KVM_CAP_MEM_FAULT_NOWAIT is not present. > + > +Enables (state=true) or disables (state=false) waitless memory faults. For more > +information, see the documentation of KVM_CAP_MEM_FAULT_NOWAIT. Why not use KVM_ENABLE_CAP instead for this? Its a preexisting UAPI for toggling KVM behaviors. > 5. The kvm_run structure > ======================== > > @@ -6544,6 +6556,21 @@ array field represents return values. The userspace should update the return > values of SBI call before resuming the VCPU. For more details on RISC-V SBI > spec refer, https://github.com/riscv/riscv-sbi-doc. > > +:: > + > + /* KVM_EXIT_MEMORY_FAULT */ > + struct { > + __u64 gpa; > + __u64 size; > + } memory_fault; > + > +If exit reason is KVM_EXIT_MEMORY_FAULT then it indicates that the VCPU has > +encountered a memory error which is not handled by KVM kernel module and > +which userspace may choose to handle. > + > +'gpa' and 'size' indicate the memory range the error occurs at. Userspace > +may handle the error and return to KVM to retry the previous memory access. How is userspace expected to differentiate the gup_fast() failed exit from the guest-private memory exit? I don't think flags are a good idea for this, as it comes with the illusion that both events can happen on a single exit. In reality, these are mutually exclusive. A fault type/code would be better here, with the option to add flags at a later date that could be used to further describe the exit (if needed). -- Thanks, Oliver
