| Message ID | 20220118095210.1651483-10-scgl@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: Do storage key checking | expand |
Am 18.01.22 um 10:52 schrieb Janis Schoetterl-Glausch: > Availability of the KVM_CAP_S390_MEM_OP_SKEY capability signals that: > * The vcpu MEM_OP IOCTL supports storage key checking. > * The vm MEM_OP IOCTL exists. > > Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> > --- > Maybe this should be redesigned. As is, the capability mixes > support of storage keys for the vcpu ioctl with the availability > of the vm ioctl (which always supports storage keys). > > We could have two capabilities, one to indicate the availability > of the vm memop and another used to derive the available functionality. > Janosch suggested that the second capability indicates the availability > of a "query" memop operation. I think one capability covering both changes is totally fine as long as we document that in api.rst. > > arch/s390/kvm/kvm-s390.c | 1 + > include/uapi/linux/kvm.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c > index ab07389fb4d9..3c6517ad43a3 100644 > --- a/arch/s390/kvm/kvm-s390.c > +++ b/arch/s390/kvm/kvm-s390.c > @@ -565,6 +565,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_S390_VCPU_RESETS: > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_S390_DIAG318: > + case KVM_CAP_S390_MEM_OP_SKEY: > r = 1; > break; > case KVM_CAP_SET_GUEST_DEBUG2: > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index dd04170287fd..1bb38efd1156 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204 > #define KVM_CAP_ARM_MTE 205 > #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206 > +#define KVM_CAP_S390_MEM_OP_SKEY 209 > > #ifdef KVM_CAP_IRQ_ROUTING >
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index ab07389fb4d9..3c6517ad43a3 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -565,6 +565,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_S390_VCPU_RESETS: case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_S390_DIAG318: + case KVM_CAP_S390_MEM_OP_SKEY: r = 1; break; case KVM_CAP_SET_GUEST_DEBUG2: diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index dd04170287fd..1bb38efd1156 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204 #define KVM_CAP_ARM_MTE 205 #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206 +#define KVM_CAP_S390_MEM_OP_SKEY 209 #ifdef KVM_CAP_IRQ_ROUTING
Availability of the KVM_CAP_S390_MEM_OP_SKEY capability signals that: * The vcpu MEM_OP IOCTL supports storage key checking. * The vm MEM_OP IOCTL exists. Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> --- Maybe this should be redesigned. As is, the capability mixes support of storage keys for the vcpu ioctl with the availability of the vm ioctl (which always supports storage keys). We could have two capabilities, one to indicate the availability of the vm memop and another used to derive the available functionality. Janosch suggested that the second capability indicates the availability of a "query" memop operation. arch/s390/kvm/kvm-s390.c | 1 + include/uapi/linux/kvm.h | 1 + 2 files changed, 2 insertions(+)