[BUG] Intel Alder Lake guest PMU unusable because Xen vPMU rejects IA32_PERF_GLOBAL_CTRL bit 48

[BUG] Intel Alder Lake guest PMU unusable because Xen vPMU rejects IA32_PERF_GLOBAL_CTRL bit 48

[Mr. Hoorn]

[-- Attachment #1.1.1: Type: text/plain, Size: 2299 bytes --]

Hi,
I have isolated what appears to be an incompatibility between Xen's Intel vPMU implementation and Linux's Alder Lake hybrid PMU initialization.

Host:

Qubes OS
Xen 4.17.5
vpmu=1
/sys/hypervisor/pmu/pmu_mode = self
/sys/hypervisor/pmu/pmu_features = 0x0

Guest:

PVH
Fedora 43
Linux 7.0.11 (also reproduced with 6.12)
Alder Lake hybrid PMU detected

With an unmodified kernel, Linux reports:

Performance Events: Alderlake Hybrid events, Intel PMU driver.

but then faults while enabling the P-core PMU:

unchecked MSR access error: WRMSR to 0x38f
tried to write 0x000100070000003f
__intel_pmu_enable_all

0x38f is IA32_PERF_GLOBAL_CTRL. The failing value contains bit 48 (GLOBAL_CTRL_EN_PERF_METRICS).

On Alder Lake, Linux explicitly enables this for the hybrid_big PMU in arch/x86/events/intel/core.c:

} else if (pmu->pmu_type & hybrid_big) {
    pmu->intel_cap.perf_metrics = 1;

Xen 4.17's Intel vPMU appears not to include bit 48 in the accepted global control mask and consequently rejects the MSR write.

The practical result is that ordinary hardware counters are also unusable. For example, perf stat reported zero cycles/instructions.

As a diagnostic workaround I built Linux 7.0.11 with only:

pmu->intel_cap.perf_metrics = 1;

changed to:

pmu->intel_cap.perf_metrics = 0;

After booting that kernel, the WRMSR fault disappears completely and ordinary PMU counters immediately work:

12,228,346,996  cpu_core/cycles/
27,471,544,939  cpu_core/instructions/

A repeated run produced approximately the same instruction count and sensible cycle counts.

So the issue appears causal: Linux enables Alder Lake P-core PERF_METRICS through IA32_PERF_GLOBAL_CTRL[48], Xen rejects that bit, and PMU initialization is effectively broken as a consequence.

I have not yet tested current xen.git, so this may already have been addressed after 4.17. Is bit 48 / Intel PERF_METRICS supported by the current vPMU implementation? If not, I think Xen should either virtualize it or expose PMU capabilities such that the guest does not attempt to enable it.

I can provide further traces or test a Xen patch if useful.

Fine regards, Met vriendelijke groeten,Matthew David van der Hoorn

LinkedIn
Sent with Proton Mail secure email.

[-- Attachment #1.1.2.1: Type: text/html, Size: 4411 bytes --]

[-- Attachment #1.2: publickey - md.career@protonmail.com - 0x4FCD90CD.asc --]
[-- Type: application/pgp-keys, Size: 661 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

Re: [BUG] Intel Alder Lake guest PMU unusable because Xen vPMU rejects IA32_PERF_GLOBAL_CTRL bit 48

[Andrew Cooper]

On 12/09/2026 1:56 pm, Mr. Hoorn wrote:
> Hi,
>
> I have isolated what appears to be an incompatibility between Xen's
> Intel vPMU implementation and Linux's Alder Lake hybrid PMU
> initialization.
>
> Host:
>
> Qubes OS
> Xen 4.17.5
> vpmu=1
> /sys/hypervisor/pmu/pmu_mode = self
> /sys/hypervisor/pmu/pmu_features = 0x0
>
> Guest:
>
> PVH
> Fedora 43
> Linux 7.0.11 (also reproduced with 6.12)
> Alder Lake hybrid PMU detected
>
> With an unmodified kernel, Linux reports:
>
> Performance Events: Alderlake Hybrid events, Intel PMU driver.
>
> but then faults while enabling the P-core PMU:
>
> unchecked MSR access error: WRMSR to 0x38f
> tried to write 0x000100070000003f
> __intel_pmu_enable_all
>
> 0x38f is IA32_PERF_GLOBAL_CTRL. The failing value contains bit 48
> (GLOBAL_CTRL_EN_PERF_METRICS).
>
> On Alder Lake, Linux explicitly enables this for the hybrid_big PMU in
> arch/x86/events/intel/core.c:
>
> } else if (pmu->pmu_type & hybrid_big) {
>     pmu->intel_cap.perf_metrics = 1;
>
> Xen 4.17's Intel vPMU appears not to include bit 48 in the accepted
> global control mask and consequently rejects the MSR write.
>
> The practical result is that ordinary hardware counters are also
> unusable. For example, perf stat reported zero cycles/instructions.
>
> As a diagnostic workaround I built Linux 7.0.11 with only:
>
> pmu->intel_cap.perf_metrics = 1;
>
> changed to:
>
> pmu->intel_cap.perf_metrics = 0;
>
> After booting that kernel, the WRMSR fault disappears completely and
> ordinary PMU counters immediately work:
>
> 12,228,346,996  cpu_core/cycles/
> 27,471,544,939  cpu_core/instructions/
>
> A repeated run produced approximately the same instruction count and
> sensible cycle counts.
>
> So the issue appears causal: Linux enables Alder Lake P-core
> PERF_METRICS through IA32_PERF_GLOBAL_CTRL[48], Xen rejects that bit,
> and PMU initialization is effectively broken as a consequence.
>
> I have not yet tested current xen.git, so this may already have been
> addressed after 4.17. Is bit 48 / Intel PERF_METRICS supported by the
> current vPMU implementation? If not, I think Xen should either
> virtualize it or expose PMU capabilities such that the guest does not
> attempt to enable it.
>
> I can provide further traces or test a Xen patch if useful.

Thankyou for the report, but this won't have been fixed.

Xen has no real knowledge of Hybrid; this is a known and out standing issue.

~Andrew