On 2026/07/30 3:18, Fuad Tabba wrote:
> Hi Akihiko,
>
> On Mon, 20 Jul 2026 at 06:39, Akihiko Odaki
> <odaki at rsg.ci.i.u-tokyo.ac.jp> 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/20260720-hybrid-v9-0-2b713ca1b5dc@rsg.ci.i.u-tokyo.ac.jp?part=6
Regards,
Akihiko Odaki