On Thu, Dec 23, 2021, Chao Peng wrote:
> This new exit allows user space to handle memory-related errors.
> Currently it supports two types (KVM_EXIT_MEM_MAP_SHARED/PRIVATE) of
> errors which are used for shared memory <-> private memory conversion
> in memory encryption usage.
>
> After private memory is enabled, there are two places in KVM that can
> exit to userspace to trigger private <-> shared conversion:
> - explicit conversion: happens when guest explicitly calls into KVM to
> map a range (as private or shared), KVM then exits to userspace to
> do the map/unmap operations.
> - implicit conversion: happens in KVM page fault handler.
> * if the fault is due to a private memory access then causes a
> userspace exit for a shared->private conversion request when the
> page has not been allocated in the private memory backend.
> * If the fault is due to a shared memory access then causes a
> userspace exit for a private->shared conversion request when the
> page has already been allocated in the private memory backend.
>
> Signed-off-by: Yu Zhang <yu.c.zhang@xxxxxxxxxxxxxxx>
> Signed-off-by: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx>
> ---
> include/uapi/linux/kvm.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 41434322fa23..d68db3b2eeec 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -243,6 +243,18 @@ struct kvm_xen_exit {
> } u;
> };
>
> +struct kvm_memory_exit {
> +#define KVM_EXIT_MEM_MAP_SHARED 1
> +#define KVM_EXIT_MEM_MAP_PRIVATE 2
I don't think the exit should explicitly say "map", it's userspace's decision on
what to do in response to the exit, i. e. describe the properties of the exit,
not what userspace should do in response to the exit.
> + __u32 type;
Hmm, I think private vs. shared should be a flag, not a type, and should be split
out from the type of error, i.e. !KVM_EXIT_MEMORY_PRIVATE == KVM_EXIT_MEMORY_SHARED.
By error type I mean page fault vs. KVM access vs. ???. And we'll probably want to
communicate read/write/execute information as well.
To get this uABI right the first time, I think we should implement this support
in advance of this series and wire up all architectures to use the new exit reason
instead of -EFAULT. It's mostly just page fault handlers, but KVM access to guest
memory, e.g. when reading/writing steal_time, also needs to use this new exit
reason.
Having two __u32s for "error" and "flags" would also pad things so that the __u64s
are correctly aligned.
> + union {
> + struct {
> + __u64 gpa;
> + __u64 size;
> + } map;
> + } u;
I'd strongly prefer to avoid another union, those get nasty when userspace just
wants to dump the info because then the meaning of each field is conditional on
the flags/error. I don't we'll get _that_ many fields, certainly far fewer than
256 bytes total, so the footprint really isn't an issue.
> +};
> +
> #define KVM_S390_GET_SKEYS_NONE 1
> #define KVM_S390_SKEYS_MAX 1048576
>
> @@ -282,6 +294,7 @@ struct kvm_xen_exit {
> #define KVM_EXIT_X86_BUS_LOCK 33
> #define KVM_EXIT_XEN 34
> #define KVM_EXIT_RISCV_SBI 35
> +#define KVM_EXIT_MEMORY_ERROR 36
>
> /* For KVM_EXIT_INTERNAL_ERROR */
> /* Emulate instruction failed. */
> @@ -499,6 +512,8 @@ struct kvm_run {
> unsigned long args[6];
> unsigned long ret[2];
> } riscv_sbi;
> + /* KVM_EXIT_MEMORY_ERROR */
> + struct kvm_memory_exit mem;
As gross as it is to make struct kvm_run super long, I actually prefer the inline
definitions, e.g.
struct {
__u32 flags;
__u32 padding;
__u64 gpa;
__u64 size;
} memory;
> /* Fix the size of the union. */
> char padding[256];
> };
> --
> 2.17.1
>
