On Tue, Oct 25, 2022, at 8:13 AM, Chao Peng wrote: > This new KVM exit allows userspace to handle memory-related errors. It > indicates an error happens in KVM at guest memory range [gpa, gpa+size). > The flags includes additional information for userspace to handle the > error. Currently bit 0 is defined as 'private memory' where '1' > indicates error happens due to private memory access and '0' indicates > error happens due to shared memory access. > > When private memory is enabled, this new exit will be used for KVM to > exit to userspace for shared <-> private memory conversion in memory > encryption usage. In such usage, typically there are two kind of memory > conversions: > - explicit conversion: happens when guest explicitly calls into KVM > to map a range (as private or shared), KVM then exits to userspace > to perform the map/unmap operations. > - implicit conversion: happens in KVM page fault handler where KVM > exits to userspace for an implicit conversion when the page is in a > different state than requested (private or shared). > > Suggested-by: Sean Christopherson <seanjc@xxxxxxxxxx> > Co-developed-by: Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx> > Signed-off-by: Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx> > Signed-off-by: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx> > --- > Documentation/virt/kvm/api.rst | 23 +++++++++++++++++++++++ > include/uapi/linux/kvm.h | 9 +++++++++ > 2 files changed, 32 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst > b/Documentation/virt/kvm/api.rst > index f3fa75649a78..975688912b8c 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6537,6 +6537,29 @@ 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 { > + #define KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 0) > + __u32 flags; > + __u32 padding; > + __u64 gpa; > + __u64 size; > + } memory; > + Would it make sense to also have a field for the access type (read, write, execute, etc)? I realize that shared <-> private conversion doesn't strictly need this, but it seems like it could be useful for logging failures and also for avoiding a second immediate fault if the type gets converted but doesn't have the right protection yet. (Obviously, if this were changed, KVM would need the ability to report that it doesn't actually know the mode.) --Andy
