On 28.05.19 10:35, Suraj Jitindar Singh wrote:
> KVM capabilities are used to communicate the availability of certain
> capabilities to userspace.
>
> It might be nice to know these values without having to add debug
> printing to the userspace tool consuming this data.
>
> Thus add a file in the kvm per vm debugfs file named "caps" which
> contains a file for each capability number which when read returns what
> would be returned when querying that capability.
>
> Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@xxxxxxxxx>
>
> ---
>
> I'm not sure if it'd be better to keep a per arch list of the revelevant
> capabilities to avoid adding an entry for irrelevant ones. Comments?
> ---
> include/linux/kvm_host.h | 1 +
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/kvm_main.c | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 33 insertions(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 79fa4426509c..6cb45a8de818 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -500,6 +500,7 @@ struct kvm {
> bool manual_dirty_log_protect;
> struct dentry *debugfs_dentry;
> struct kvm_stat_data **debugfs_stat_data;
> + int debugfs_cap_data[KVM_CAP_MAX + 1];
> struct srcu_struct srcu;
> struct srcu_struct irq_srcu;
> pid_t userspace_pid;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 2fe12b40d503..7b5042ec5902 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_ARM_SVE 170
> #define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
> #define KVM_CAP_ARM_PTRAUTH_GENERIC 172
> +#define KVM_CAP_MAX KVM_CAP_ARM_PTRAUTH_GENERIC
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 134ec0283a8a..b85a43263fb7 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -117,6 +117,7 @@ EXPORT_SYMBOL_GPL(kvm_debugfs_dir);
> static int kvm_debugfs_num_entries;
> static const struct file_operations *stat_fops_per_vm[];
>
> +static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg);
> static long kvm_vcpu_ioctl(struct file *file, unsigned int ioctl,
> unsigned long arg);
> #ifdef CONFIG_KVM_COMPAT
> @@ -594,6 +595,33 @@ static void kvm_destroy_vm_debugfs(struct kvm *kvm)
> }
> }
>
> +static int vm_cap_get(void *data, u64 *val)
> +{
> + *val = *((int *) data);
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(cap_fops, vm_cap_get, NULL, "%llu\n");
> +
> +static void kvm_create_vm_cap_debugfs(struct kvm *kvm)
> +{
> + char *dir_name = "caps";
> + struct dentry *dentry_p;
> + int i;
> +
> + dentry_p = debugfs_create_dir(dir_name, kvm->debugfs_dentry);
> +
> + for (i = 0; i <= KVM_CAP_MAX; i++) {
> + int *cap = &kvm->debugfs_cap_data[i];
> + char file_name[ITOA_MAX_LEN];
> +
> + *cap = kvm_vm_ioctl_check_extension_generic(kvm, i);
> + snprintf(file_name, sizeof(file_name), "%d", i);
> + debugfs_create_file(file_name, 0444, dentry_p, cap, &cap_fops);
> + }
So you get the information of the capabilities during creation of the VM.
Are there any capabilities that might change over time? I do not know right
now, but wouldnt it be better to actually call kvm_vm_ioctl_check_extension_generic
in the fops callback?
> +}
> +
> static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
> {
> char dir_name[ITOA_MAX_LEN * 2];
> @@ -623,6 +651,9 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd)
> debugfs_create_file(p->name, 0644, kvm->debugfs_dentry,
> stat_data, stat_fops_per_vm[p->kind]);
> }
> +
> + kvm_create_vm_cap_debugfs(kvm);
> +
> return 0;
> }
>
