[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Mr. Hoorn" <md.career@xxxxxxxxxxxxxx>
  • Date: Sat, 12 Sep 2026 12:56:38 +0000
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=protonmail3 header.d=protonmail.com header.i="@protonmail.com" header.h="Date:To:From:Subject:Message-ID:Feedback-ID"
  • Delivery-date: Sat, 12 Sep 2026 13:44:50 +0000
  • Feedback-id: 94398300:user:proton
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

Sent with Proton Mail secure email.

Attachment: publickey - md.career@protonmail.com - 0x4FCD90CD.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.