Re: [PATCH 3/3] KVM: x86/svm/pmu: Drop 'enum index' for more counters scalability

[Like Xu]

The third patch is buggy, please ignore it.
I will post a new version. Sorry for the noise.

On 10/5/2022 7:57 pm, Like Xu wrote:
> From: Like Xu<likexu@xxxxxxxxxxx>
>
> If the number of AMD gp counters continues to grow, the code will
> be very clumsy and the switch-case design of inline get_gp_pmc_amd()
> will also bloat the kernel text size.
>
> The target code is taught to manage two groups of MSRs, each
> representing a different version of the AMD PMU counter MSRs.
> The MSR addresses of each group are contiguous, with no holes,
> and there is no intersection between two sets of addresses,
> but they are discrete in functionality by design like this:
>
> [Group A : All counter MSRs are tightly bound to all event select MSRs ]
>
>    MSR_K7_EVNTSEL0			0xc0010000
>    MSR_K7_EVNTSELi			0xc0010000 + i
>    ...
>    MSR_K7_EVNTSEL3			0xc0010003
>    MSR_K7_PERFCTR0			0xc0010004
>    MSR_K7_PERFCTRi			0xc0010004 + i
>    ...
>    MSR_K7_PERFCTR3			0xc0010007
>
> [Group B : The counter MSRs are interleaved with the event select MSRs ]
>
>    MSR_F15H_PERF_CTL0		0xc0010200
>    MSR_F15H_PERF_CTR0		(0xc0010200 + 1)
>    ...
>    MSR_F15H_PERF_CTLi		(0xc0010200 + 2 * i)
>    MSR_F15H_PERF_CTRi		(0xc0010200 + 2 * i + 1)
>    ...
>    MSR_F15H_PERF_CTL5		(0xc0010200 + 2 * 5)
>    MSR_F15H_PERF_CTR5		(0xc0010200 + 2 * 5 + 1)
>
> Rewrite get_gp_pmc_amd() in this way: first determine which group of
> registers is accessed by the pass-in 'msr' address, then determine
> which msr 'base' is referenced by 'type', applying different address
> scaling ratios separately, and finally get the pmc_idx.
>
> If the 'base' does not match its 'type', it continues to remain invalid.
>
> Signed-off-by: Like Xu<likexu@xxxxxxxxxxx>