Hi Sean,
Thank you for reviewing my patches. Sorry for the delay in response.
On 8/13/2024 10:07 PM, Sean Christopherson wrote:
> On Tue, May 28, 2024, Manali Shukla wrote:
>> From: Manali Shukla <manali.shu...@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.shu...@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.
All the review comments from this patch are taken care in [1].
[1]
https://lore.kernel.org/kvm/20241021062226.108657-1-manali.shu...@amd.com/T/#t
- Manali
