Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit
From: "Andy Lutomirski" <luto@kernel.org>
Date: 2022-11-16 18:16:27
Also in:
kvm, linux-arch, linux-doc, linux-fsdevel, linux-mm, lkml, qemu-devel
On Tue, Oct 25, 2022, at 8:13 AM, Chao Peng wrote:
quoted hunk ↗ jump to hunk
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@google.com> Co-developed-by: Yu Zhang <redacted> Signed-off-by: Yu Zhang <redacted> Signed-off-by: Chao Peng <redacted> --- Documentation/virt/kvm/api.rst | 23 +++++++++++++++++++++++ include/uapi/linux/kvm.h | 9 +++++++++ 2 files changed, 32 insertions(+)diff --git a/Documentation/virt/kvm/api.rstb/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. Theuserspace 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