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 <jbeul...@suse.com>
>> ---
>> 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
