Message ID | 20220907104838.8424-1-likexu@tencent.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2,1/3] KVM: x86/pmu: Stop adding speculative Intel GP PMCs that don't exist yet | expand |
On Wed, Sep 7, 2022 at 3:48 AM Like Xu <like.xu.linux@gmail.com> wrote: > > From: Like Xu <likexu@tencent.com> > > The Intel April 2022 SDM - Table 2-2. IA-32 Architectural MSRs adds > a new architectural IA32_OVERCLOCKING_STATUS msr (0x195), plus the > presence of IA32_CORE_CAPABILITIES (0xCF), the theoretical effective > maximum value of the Intel GP PMCs is 14 (0xCF - 0xC1) instead of 18. > > But the conclusion of this speculation "14" is very fragile and can > easily be overturned once Intel declares another meaningful arch msr > in the above reserved range, and even worse, Intel probably put PMCs > 8-15 in a completely different range of MSR indices. The last clause is just conjecture. > A conservative proposal would be to stop at the maximum number of Intel > GP PMCs supported today. Also subsequent changes would limit both AMD > and Intel on the number of GP counter supported by KVM. > > There are some boxes like Intel P4 may indeed have 18 counters, but > those counters are in a completely different msr address range and do > not strictly adhere to the Intel Arch PMU specification, and will not > be supported by KVM in the near future. The P4 PMU isn't virtualized by KVM today, is it? > > Cc: Vitaly Kuznetsov <vkuznets@redhat.com> > Suggested-by: Jim Mattson <jmattson@google.com> > Signed-off-by: Like Xu <likexu@tencent.com> Please put the "Fixes" tag back. You convinced me that it should be there. Reviewed-by: Jim Mattson <jmattson@google.com>
On 8/9/2022 12:33 am, Jim Mattson wrote: > On Wed, Sep 7, 2022 at 3:48 AM Like Xu <like.xu.linux@gmail.com> wrote: >> >> From: Like Xu <likexu@tencent.com> >> >> The Intel April 2022 SDM - Table 2-2. IA-32 Architectural MSRs adds >> a new architectural IA32_OVERCLOCKING_STATUS msr (0x195), plus the >> presence of IA32_CORE_CAPABILITIES (0xCF), the theoretical effective >> maximum value of the Intel GP PMCs is 14 (0xCF - 0xC1) instead of 18. >> >> But the conclusion of this speculation "14" is very fragile and can >> easily be overturned once Intel declares another meaningful arch msr >> in the above reserved range, and even worse, Intel probably put PMCs >> 8-15 in a completely different range of MSR indices. > > The last clause is just conjecture. > >> A conservative proposal would be to stop at the maximum number of Intel >> GP PMCs supported today. Also subsequent changes would limit both AMD >> and Intel on the number of GP counter supported by KVM. >> >> There are some boxes like Intel P4 may indeed have 18 counters, but >> those counters are in a completely different msr address range and do >> not strictly adhere to the Intel Arch PMU specification, and will not >> be supported by KVM in the near future. > > The P4 PMU isn't virtualized by KVM today, is it? According to [1], P4 PMU has ZERO number of Intel Architectural Events, and the KVM support for non Intel Arch PMUs has been dropped recently. [1] https://www.intel.com/content/dam/develop/external/us/en/documents/30320-nehalem-pmu-programming-guide-core.pdf > >> >> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> >> Suggested-by: Jim Mattson <jmattson@google.com> >> Signed-off-by: Like Xu <likexu@tencent.com> > > Please put the "Fixes" tag back. You convinced me that it should be there. > > Reviewed-by: Jim Mattson <jmattson@google.com>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 43a6a7efc6ec..884f6de11a33 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1428,20 +1428,10 @@ static const u32 msrs_to_save_all[] = { MSR_ARCH_PERFMON_PERFCTR0 + 2, MSR_ARCH_PERFMON_PERFCTR0 + 3, MSR_ARCH_PERFMON_PERFCTR0 + 4, MSR_ARCH_PERFMON_PERFCTR0 + 5, MSR_ARCH_PERFMON_PERFCTR0 + 6, MSR_ARCH_PERFMON_PERFCTR0 + 7, - MSR_ARCH_PERFMON_PERFCTR0 + 8, MSR_ARCH_PERFMON_PERFCTR0 + 9, - MSR_ARCH_PERFMON_PERFCTR0 + 10, MSR_ARCH_PERFMON_PERFCTR0 + 11, - MSR_ARCH_PERFMON_PERFCTR0 + 12, MSR_ARCH_PERFMON_PERFCTR0 + 13, - MSR_ARCH_PERFMON_PERFCTR0 + 14, MSR_ARCH_PERFMON_PERFCTR0 + 15, - MSR_ARCH_PERFMON_PERFCTR0 + 16, MSR_ARCH_PERFMON_PERFCTR0 + 17, MSR_ARCH_PERFMON_EVENTSEL0, MSR_ARCH_PERFMON_EVENTSEL1, MSR_ARCH_PERFMON_EVENTSEL0 + 2, MSR_ARCH_PERFMON_EVENTSEL0 + 3, MSR_ARCH_PERFMON_EVENTSEL0 + 4, MSR_ARCH_PERFMON_EVENTSEL0 + 5, MSR_ARCH_PERFMON_EVENTSEL0 + 6, MSR_ARCH_PERFMON_EVENTSEL0 + 7, - MSR_ARCH_PERFMON_EVENTSEL0 + 8, MSR_ARCH_PERFMON_EVENTSEL0 + 9, - MSR_ARCH_PERFMON_EVENTSEL0 + 10, MSR_ARCH_PERFMON_EVENTSEL0 + 11, - MSR_ARCH_PERFMON_EVENTSEL0 + 12, MSR_ARCH_PERFMON_EVENTSEL0 + 13, - MSR_ARCH_PERFMON_EVENTSEL0 + 14, MSR_ARCH_PERFMON_EVENTSEL0 + 15, - MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17, MSR_IA32_PEBS_ENABLE, MSR_IA32_DS_AREA, MSR_PEBS_DATA_CFG, MSR_K7_EVNTSEL0, MSR_K7_EVNTSEL1, MSR_K7_EVNTSEL2, MSR_K7_EVNTSEL3, @@ -6943,12 +6933,12 @@ static void kvm_init_msr_list(void) intel_pt_validate_hw_cap(PT_CAP_num_address_ranges) * 2) continue; break; - case MSR_ARCH_PERFMON_PERFCTR0 ... MSR_ARCH_PERFMON_PERFCTR0 + 17: + case MSR_ARCH_PERFMON_PERFCTR0 ... MSR_ARCH_PERFMON_PERFCTR0 + 7: if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_PERFCTR0 >= min(INTEL_PMC_MAX_GENERIC, kvm_pmu_cap.num_counters_gp)) continue; break; - case MSR_ARCH_PERFMON_EVENTSEL0 ... MSR_ARCH_PERFMON_EVENTSEL0 + 17: + case MSR_ARCH_PERFMON_EVENTSEL0 ... MSR_ARCH_PERFMON_EVENTSEL0 + 7: if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >= min(INTEL_PMC_MAX_GENERIC, kvm_pmu_cap.num_counters_gp)) continue;