Re: [RFC PATCH v3 03/11] KVM: Introduce KVM_CAP_ARM_HVC_FW_REG_BMAP
From: Reiji Watanabe <hidden>
Date: 2022-01-08 05:40:34
Also in:
kvm, kvmarm, lkml
Hi Raghu, On Tue, Jan 4, 2022 at 11:49 AM Raghavendra Rao Ananta [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Introduce the KVM ARM64 capability, KVM_CAP_ARM_HVC_FW_REG_BMAP, to indicate the support for psuedo-firmware bitmap extension. Each of these registers holds a feature-set exposed to the guest in the form of a bitmap. If supported, a simple 'read' of the capability should return the number of psuedo-firmware registers supported. User-space can utilize this to discover the registers. It can further explore or modify the features using the classical GET/SET_ONE_REG interface. Signed-off-by: Raghavendra Rao Ananta <redacted> --- Documentation/virt/kvm/api.rst | 21 +++++++++++++++++++++ include/uapi/linux/kvm.h | 1 + 2 files changed, 22 insertions(+)diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index aeeb071c7688..646176537f2c 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst@@ -6925,6 +6925,27 @@ indicated by the fd to the VM this is called on. This is intended to support intra-host migration of VMs between userspace VMMs, upgrading the VMM process without interrupting the guest. +7.30 KVM_CAP_ARM_HVC_FW_REG_BMAP
IMHO, instead of including its format of the register in the name, including its purpose/function in the name might be better. e.g. KVM_CAP_ARM_HVC_FEATURE_REG ? (Feature fields don't necessarily have to be in a bitmap format if they don't fit well although I'm not sure if we have such fields.)
+-------------------------------- + +:Architectures: arm64 +:Parameters: None +:Returns: Number of psuedo-firmware registers supported
Looking at patch-4, the return value of this would be the number of pseudo-firmware *bitmap* registers supported. BTW, "4.68 KVM_SET_ONE_REG" in the doc uses the word "arm64 firmware pseudo-registers". It would be nicer to use the same term.
+ +This capability indicates that KVM for arm64 supports the psuedo-firmware +register bitmap extension. Each of these registers represent the features +supported by a particular type in the form of a bitmap. By default, these +registers are set with the upper limit of the features that are supported. + +The registers can be accessed via the standard SET_ONE_REG and KVM_GET_ONE_REG +interfaces. The user-space is expected to read the number of these registers +available by reading KVM_CAP_ARM_HVC_FW_REG_BMAP, read the current bitmap +configuration via GET_ONE_REG for each register, and then write back the +desired bitmap of features that it wishes the guest to see via SET_ONE_REG. + +Note that KVM doesn't allow the user-space to modify these registers after +the VM (any of the vCPUs) has started running.
Since even if KVM_RUN fails, and the VM hasn't started yet, it will get immutable. So, "after any of the vCPUs run KVM_RUN." might be more clear ? Thanks, Reiji
quoted hunk ↗ jump to hunk
+ 8. Other capabilities. ======================diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 1daa45268de2..209b43dbbc3c 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h@@ -1131,6 +1131,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_ARM_HVC_FW_REG_BMAP 207 #ifdef KVM_CAP_IRQ_ROUTING --2.34.1.448.ga2b2bfdf31-goog
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel