Re: [PATCH 4/5] SVM: sync VM-exit perf counters with known VM-exit reasons

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.12.2021 16:02, Andrew Cooper wrote:
> On 03/12/2021 12:06, Jan Beulich wrote:
>> This has gone out of sync over time, resulting in NPF and XSETBV exits
>> incrementing the same counter. Introduce a simplistic mechanism to
>> hopefully keep things in better sync going forward.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Given their large (and growing) number, I wonder whether we shouldn't
>> fold "SVMexits" and "vmexits". They can't both be active at the same
>> time.
> 
> Oh yeah - that's just silly having them split like this, especially as
> there's no associated element name.

Okay, will do. Albeit I was thinking to add naming to xenperf ...

>> --- a/xen/include/asm-x86/perfc_defn.h
>> +++ b/xen/include/asm-x86/perfc_defn.h
>> @@ -11,8 +11,8 @@ PERFCOUNTER_ARRAY(exceptions,
>>  PERFCOUNTER_ARRAY(vmexits,              "vmexits", 
>> VMX_PERF_EXIT_REASON_SIZE)
>>  PERFCOUNTER_ARRAY(cause_vector,         "cause vector", 
>> VMX_PERF_VECTOR_SIZE)
>>  
>> -#define VMEXIT_NPF_PERFC 141
>> -#define SVM_PERF_EXIT_REASON_SIZE (1+141)
>> +#define VMEXIT_NPF_PERFC 143
>> +#define SVM_PERF_EXIT_REASON_SIZE (VMEXIT_NPF_PERFC + 1)
> 
> How does this work in the first place?  perfc_incra() is still passed 1024.

In

    case VMEXIT_NPF:
        perfc_incra(svmexits, VMEXIT_NPF_PERFC);

I don't see any use of 1024. And the earlier blanket

    perfc_incra(svmexits, exit_reason);

doesn't do anything afaict, due to how perfc_incra() works.

> Furthermore, it's already worse than this.
> 
> 401/402 are AVIC exits, and 403 is an SEV exit.

In which way is this "worse"? We don't support either AVIC or SEV (which
is a shame in particular for the former, but what do you do with vendors
having given up all engagement).

>  We've also gained -2 as "busy" for transient SEV events too.

I'm sorry, I'm not enough up to speed with SEV yet to even vaguely know
what you're referring to here.

Jan