On Tue, 07 Jul 2026 09:10:17 +0100,
Oliver Upton [off-list ref] wrote:

On Tue, Jul 07, 2026 at 08:58:50AM +0100, Marc Zyngier wrote:

quoted

On Mon, 06 Jul 2026 19:28:20 +0100,
Oliver Upton [off-list ref] wrote:

quoted

On Mon, Jul 06, 2026 at 07:03:23PM +0900, Akihiko Odaki wrote:

quoted

Akihiko Odaki (7):
      KVM: arm64: Disallow vPMU when pPMUs do not cover all CPUs
      KVM: arm64: PMU: Protect the list of PMUs with RCU
      KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event()
      KVM: arm64: PMU: Pass the target CPU to kvm_pmu_probe_armpmu()
      KVM: arm64: PMU: Implement fixed-counters-only emulation
      KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
      KVM: arm64: selftests: Test PMU_V3_FIXED_COUNTERS_ONLY

Thanks for respinning the series, I left some comments. I'd really like
to get this feature picked up, hope you have cycles to work on it soon.

FWIW, we're considering adding a new vCPU feature flag to deprecate all
the ugliness of the old PMUv3 UAPI. I'm tempted to say that the
FIXED_COUNTERS_ONLY feature is conditioned on the new feature flag...

It'd be good to have a strawman proposal on the list if we are going
to change add a new API, specially if this is likely to gate new code.

Patch 1 [*] of the series I linked does exactly this, no? Needs some

Ah, I overlooked that, apologies.

attention like a KVM_CAP to make the bit discoverable by the VMM but
gets the general idea across.

Not sure that's the ideal approach, specially in the light of this
"multiple PMU" series. This "strict" API mandates the selection of a
PMU (singular), while this stuff is the exact opposite (grab all the
possible PMUs).

	M.

-- 
Without deviation from the norm, progress is not possible.