Re: [PATCH v3 4/5] KVM: selftests: Add an interface to read the data of named vcpu stat

[Sean Christopherson <seanjc@google.com>]

On Tue, May 28, 2024, Manali Shukla wrote:
> From: Manali Shukla <Manali.Shukla@amd.com>
> 
> The interface is used to read the data values of a specified vcpu stat
> from the currenly available binary stats interface.
> 
> Signed-off-by: Manali Shukla <Manali.Shukla@amd.com>
> ---
>  .../kvm/include/kvm_arch_vcpu_states.h        | 49 +++++++++++++++++++
>  .../testing/selftests/kvm/include/kvm_util.h  | 34 +++++++++++++
>  tools/testing/selftests/kvm/lib/kvm_util.c    | 32 ++++++++++++
>  3 files changed, 115 insertions(+)
>  create mode 100644 tools/testing/selftests/kvm/include/kvm_arch_vcpu_states.h
> 
> diff --git a/tools/testing/selftests/kvm/include/kvm_arch_vcpu_states.h b/tools/testing/selftests/kvm/include/kvm_arch_vcpu_states.h
> new file mode 100644
> index 000000000000..755ff7de53d9
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/include/kvm_arch_vcpu_states.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Arch-specific stats are added to the kvm_arch_vcpu_states.h. Sequence
> + * of arch-specific vcpu_stat_type should be same as they are declared in
> + * arch-specific kvm_vcpu_stat.
> + */
> +#ifdef __x86_64__

This is backwards.  If you want arch specific stats, put it them in an arch specific
header.

> +#define KVM_X86_VCPU_STATE(x) KVM_VCPU_STATE(x)
> +
> +KVM_X86_VCPU_STATE(PF_TAKEN)

I'm pretty sure you want KVM_VCPU_STAT, KVM_X86_VCPU_STAT, kvm_arch_vcpu_states.h,
etc.

> +KVM_X86_VCPU_STATE(PF_FIXED)

...

> +/*
> + * Ensure that the sequence of the enum vcpu_stat_types matches the order of
> + * kvm_vcpu_stats_desc[].  Otherwise, vcpu_get_stat() may return incorrect data
> + * because __vcpu_get_stat() uses the enum type as an index to get the
> + * descriptor for a given stat and then uses read_stat_data() to get the stats
> + * from the descriptor.

This isn't maintainable.  Unless I'm missing something, the _order_ of KVM's stats
isn't ABI, and blindly reading an entry and hoping its the right one is doomed to
fail.

I don't see any reason whatsoever to diverge from the core functionality of
__vm_get_stat().  The only difference should be the origin of the stats file and
header.

I do see a lot of room for improvement, but that can and should be done for both
VM and vCPU stats.  E.g. provide an API (and a container/struct?) to get a direct
pointer to stat so that selftests don't have to walk all descriptors when they're
reading the same stat over and over.

And to detect typos at compile time, {vcpu,vm}_get_stat() could either play macro
games or use enums and array to detect usage of a stat that doesn't exist.  E.g.

static inline uint64_t vm_get_stat(struct kvm_vm *vm, int stat)
{
	uint64_t data;

	__vm_get_stat(vm, kvm_vm_stats[stat], &data, 1);
	return data;
}

or 

#define vm_get_stat(vm, stat)			\
({						\
	uin64_t __data;				\
						\
	<concatenation trickery to trigger compiler error if the stat doesn't exit>
	__vm_get_stat(vm, #stat, &data, 1);	\
	data;					\
})

I'd probably vote for macro games, e.g. so that it's all but impossible to pass
a per-VM stat into vcpu_get_stat(), and vice versa.