Re: [PATCH v3 05/18] KVM: x86/pmu: Drop nr_arch_{gp,fixed}_counters from kvm_pmu

["Chen, Zide" <zide.chen@intel.com>]

On 11/6/2026 6:42 PM, Jim Mattson wrote:
> On Fri, Nov 6, 2026 at 11:34 AM Yosry Ahmed <yosry@kernel.org> wrote:
>>
>>> @@ -979,8 +979,6 @@ void kvm_pmu_refresh(struct kvm_vcpu *vcpu)
>>>       kvm_pmu_reset(vcpu);
>>>
>>>       pmu->version = 0;
>>> -     pmu->nr_arch_gp_counters = 0;
>>> -     pmu->nr_arch_fixed_counters = 0;
>>>       pmu->counter_bitmask[KVM_PMC_GP] = 0;
>>>       pmu->counter_bitmask[KVM_PMC_FIXED] = 0;
>>>       /*
>>> @@ -1008,16 +1006,12 @@ void kvm_pmu_refresh(struct kvm_vcpu *vcpu)
>>>        * in the global controls).  Emulate that behavior when refreshing the
>>>        * PMU so that userspace doesn't need to manually set PERF_GLOBAL_CTRL.
>>>        */
>>> -     if (pmu->nr_arch_gp_counters &&
>>> +     if (kvm_gp_pmc_mask(pmu) &&
>>>           (kvm_pmu_has_perf_global_ctrl(pmu) || kvm_vcpu_has_mediated_pmu(vcpu)))
>>> -             pmu->global_ctrl = GENMASK_ULL(pmu->nr_arch_gp_counters - 1, 0);
>>> +             pmu->global_ctrl = kvm_gp_pmc_mask(pmu);
>>>
>>>       if (kvm_vcpu_has_mediated_pmu(vcpu))
>>>               kvm_pmu_call(write_global_ctrl)(pmu->global_ctrl);
>>> -
>>> -     bitmap_set(pmu->pmc_exists, 0, pmu->nr_arch_gp_counters);
>>> -     bitmap_set(pmu->pmc_exists, KVM_FIXED_PMC_BASE_IDX,
>>> -                pmu->nr_arch_fixed_counters);
>>
>> I understand the vendor modules are responsible of initializing this
>> now, but should we clear it before calling into the vendors like other
>> fields above?
> 
> pmc_exists is zeroed further up in kvm_pmu_refresh. See patch 02/18.
> 
> [..]
> 
>>> @@ -117,7 +116,7 @@ static bool amd_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
>>>               return pmu->version > 1;
>>>       default:
>>>               if (msr > MSR_F15H_PERF_CTR5 &&
>>> -                 msr < MSR_F15H_PERF_CTL0 + 2 * pmu->nr_arch_gp_counters)
>>> +                 msr < MSR_F15H_PERF_CTL0 + 2 * hweight_long(kvm_gp_pmc_mask(pmu)))
>>
>> This assumes the MSRs are contiguous, which IIUC is always true, but I
>> wonder if it should also be handled since the series claims to also
>> prepare for discontiguous GP counters.
> 
> Actually, since KVM_MAX_NR_AMD_GP_COUNTERS is 6 and MSR_F15H_PERF_CTR5
> is MSR_F15H_PERF_CTL0 + 11, this condition is always false today,
> rendering the default case dead code. What situation is this intended
> to address?

This was carried over from commit 4a2771895ca6 ("KVM: x86/svm/pmu: Add
AMD PerfMonV2 support"). My best guess is that it anticipated supporting
>6 core counters under PerfMonV2 (since CPUID 0x80000022 EBX[3:0] allows
up to 16).

Should we remove this dead code for now (as a small, separate patch) and
add it back when KVM_MAX_NR_AMD_GP_COUNTERS is expanded?