On Tue, Mar 04, 2025, Xiaoyao Li wrote:
> On 3/3/2025 6:00 AM, Dongli Zhang wrote:
> > Although AMD PERFCORE and PerfMonV2 are removed when "-pmu" is configured,
> > there is no way to fully disable KVM AMD PMU virtualization. Neither
> > "-cpu host,-pmu" nor "-cpu EPYC" achieves this.
>
> This looks like a KVM bug.
Heh, the patches you sent do fix _a_ KVM bug, but this is something else
entirely.
In practice, the KVM bug only affects what KVM_GET_SUPPORTED_CPUID returns when
enable_pmu=false, and in that case, it's only a reporting issue, i.e. KVM will
still block usage of the PMU.
As Dongli pointed out, older AMD CPUs don't actually enumerate a PMU in CPUID,
and so the kernel assumes that not-too-old CPUs have a PMU:
/* Performance-monitoring supported from K7 and later: */
if (boot_cpu_data.x86 < 6)
return -ENODEV;
The "expected" output:
Performance Events: PMU not available due to virtualization, using software
events only.
is a long-standing workaround in the kernel to deal with lack of enumeration.
On
top of explicit enumeration, init_hw_perf_events() => check_hw_exists() probes
hardware to see if it actually works. If an MSR is unexpectedly unavailable, as
is the case when running as a guest, the kernel prints a message and disables
PMU
usage. E.g. the above message is specific to running as a guest:
if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
pr_cont("PMU not available due to virtualization, using
software events only.\n");
>From the KVM side, because there's no CPUID enumeration, there's no way for KVM
to know that userspace wants to completely disable PMU virtualization from CPUID
alone. Whereas with Intel CPUs, KVM infers that the PMU should be disabled by
lack of a non-zero PMU version, e.g. if CPUID.0xA is omitted.
> Anyway, since QEMU can achieve its goal with KVM_PMU_CAP_DISABLE with
> current KVM, I'm fine with it.
Yeah, this is the only way other than disabling KVM's PMU virtualization via
module param (enable_pmu).
