Re: [PATCH v9 14/16] KVM: arm64: PMU: Implement fixed-counters-only emulation

On 2026/07/30 3:18, Fuad Tabba wrote:
> Hi Akihiko,
> 
> On Mon, 20 Jul 2026 at 06:39, Akihiko Odaki
> <[email protected]> wrote:
> ...
> 
>> +/**
>> + * kvm_pmu_create_perf_event - create a perf event for a counter
>> + * @pmc: Counter context
>> + */
>> +static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
>> +{
>> +       struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
>> +       struct arm_pmu *arm_pmu = vcpu->kvm->arch.arm_pmu;
>> +
>> +       if (kvm_pmu_fixed_counters_only(vcpu->kvm)) {
>> +               do {
>> +                       arm_pmu = kvm_pmu_probe_armpmu(READ_ONCE(vcpu->cpu));
>> +
>> +                       if (!arm_pmu) {
>> +                               pr_warn_once("kvm: Unsupported PMU variation detected.\n");
>> +                               add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
>> +                               return;
>> +                       }
> 
> Sashiko flagged that this can leave the perf event out of sync with
> the sysreg, which looks plausible: on a pCPU with no registered pPMU
> this returns without recreating the event, so a guest event-type
> change there updates the sysreg but not the event, and after migrating
> back to a pCPU the original pPMU covers, kvm_pmc_enable_perf_event()
> re-enables the stale event instead of recreating it.
> 
> I know you treat the no-pPMU case as out of spec, but the dropped
> update lands once the vCPU is back on a normal pCPU. Is this intended?

"[PATCH v9 06/16] KVM: arm64: PMU: Recreate events after MDCR_EL2 
changes" calls kvm_pmu_stop_counter() in kvm_vcpu_reload_pmu(), so it 
does not matter whether this function calls kvm_pmu_stop_counter().

The other changes that require recreating the event are currently not 
handled at all as Sashiko complains [1]. I'll fix that as done in 
MDCR_EL2 setters in the next version.

That said, I do not intend to add any extra complexity to provide any 
guarantee for a system with unsupported PMU variation except that the 
user can notice and react to that (i.e., the taint is reported and no 
oops happens due to NULL dereference). The patch message is somewhat 
misleading in this aspect so I'm going to fix that in the next version.

[1] 
https://sashiko.dev/#/patchset/[email protected]?part=6

Regards,
Akihiko Odaki