Re: [PATCH v9 06/16] KVM: arm64: PMU: Recreate events after MDCR_EL2 changes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Modifying PMCR_EL0.LC or PMCR_EL0.LP does not recreate perf events, leading to stale sample periods for active counters.
- [Medium] Userspace modification of PMEVTYPERn_EL0 or PMCCFILTR_EL0 via KVM_SET_ONE_REG does not trigger a PMU reload or recreate the backing perf_event.
--

--- Patch [6]: [PATCH v9 06/16] KVM: arm64: PMU: Recreate events after MDCR_EL2 changes ---
commit 55bb4c8121d4871eb781b7b2feafd0970dbee364
Author: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>

KVM: arm64: PMU: Recreate events after MDCR_EL2 changes

MDCR_EL2.HPMN changes which counters are reserved for EL2 and thus which
enable control, event filter, and overflow width apply. Route guest writes,
userspace writes, and reset through a common helper to mark the vCPU's
perf events for recreation when HPMN, HPMD, or HLP changes.

> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c

[ ... ]

> @@ -606,6 +609,21 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
>  	}
>  }
>  
> +void kvm_pmu_handle_mdcr(struct kvm_vcpu *vcpu, u64 old, u64 val)
> +{
> +	u64 changed = old ^ val;
> +
> +	/*
> +	 * HPMN determines which counters HPMD and HLP apply to. Changes to
> +	 * these fields require new perf event filters and sample periods.
> +	 */
> +	if (changed & MDCR_EL2_PMU_RECREATE_MASK)
> +		vcpu->arch.pmu.events_need_recreate = true;
> +
> +	if (changed & (MDCR_EL2_HPME | MDCR_EL2_PMU_RECREATE_MASK))
> +		kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
> +}

[Severity: Medium]
This is a pre-existing issue, but modifying PMCR_EL0.LC or PMCR_EL0.LP
doesn't seem to recreate perf events.

Guest writes to PMCR_EL0 in kvm_pmu_handle_pmcr() only trigger a PMU reload
if the E bit changes, and never mark events for recreation when LC or LP
change. This also applies to userspace KVM_SET_ONE_REG writes to PMCR_EL0 via
set_pmcr(), which request a reload but fail to set
events_need_recreate = true.

Because PMCR_EL0.LC and LP determine whether the PMU counters overflow at 32
or 64 bits, does this leave the events using stale sample periods, leading
to incorrect performance statistics and mistimed overflow interrupts?

> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c

[ ... ]

> @@ -3741,7 +3751,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	EL2_REG_FILTERED(SCTLR2_EL2, access_vm_reg, reset_val, 0,
>  			 sctlr2_el2_visibility),
>  	EL2_REG_VNCR(HCR_EL2, reset_hcr, 0),
> -	EL2_REG(MDCR_EL2, access_mdcr, reset_mdcr, 0),
> +	SYS_REG_USER_FILTER(MDCR_EL2, access_mdcr, reset_mdcr, 0,
> +			    NULL, set_mdcr, el2_visibility),

[Severity: Medium]
This is also a pre-existing issue, but userspace modifications of
PMEVTYPERn_EL0 or PMCCFILTR_EL0 via KVM_SET_ONE_REG don't appear to trigger a
PMU reload or recreate the backing perf_event.

Because the macros defining PMEVTYPERn_EL0 and PMCCFILTR_EL0 in
sys_reg_descs lack a .set_user accessor, kvm_sys_reg_set_user() falls back to
__vcpu_assign_sys_reg() without requesting a PMU reload or event recreation.

If userspace modifies a vCPU's PMU event type registers after the vCPU has
already run, does the PMU continue counting the old events, leading to
incorrect statistics?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-hybrid-v9-0-2b713ca1b5dc@rsg.ci.i.u-tokyo.ac.jp?part=6