Re: [PATCH v2 1/3] KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Silent truncation of PMU event counter states and PMCR_EL0.N during VCPU sysreg restoration before PMU initialization.
--

commit 7651e4c8e75621127e5fba611a9aa7f3257fa4b2
Author: Congkai Tan <congkai@amazon.com>

KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature

This patch introduces the KVM_ARM_VCPU_PMU_V3_STRICT vCPU feature, preventing
KVM from creating a default PMU on initialization. Userspace must instead
explicitly select a PMU via KVM_ARM_VCPU_PMU_V3_SET_PMU before the first
KVM_RUN.

> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index e1860acae641f..1f24169505a91 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c

[ ... ]

> @@ -1021,6 +1024,14 @@ u8 kvm_arm_pmu_get_max_counters(struct kvm *kvm)
>  {
>  	struct arm_pmu *arm_pmu = kvm->arch.arm_pmu;
>  
> +	/*
> +	 * Under KVM_ARM_VCPU_PMU_V3_STRICT no PMU exists until userspace sets
> +	 * one, so this can be reached before arm_pmu is set. Report no
> +	 * counters in that case.
> +	 */
> +	if (!arm_pmu)
> +		return 0;
> +

[Severity: High]
Could returning 0 here before the PMU is explicitly selected cause silent
truncation of PMU event counter states during live migration?

If a VMM restores PMU sysregs via KVM_SET_ONE_REG before selecting the PMU
via KVM_ARM_VCPU_PMU_V3_SET_PMU, set_pmcr() in arch/arm64/kvm/sys_regs.c
evaluates:

arch/arm64/kvm/sys_regs.c:set_pmcr() {
    if (!kvm_vm_has_ran_once(kvm) &&
        !vcpu_has_nv(vcpu)        &&
        new_n <= kvm_arm_pmu_get_max_counters(kvm))
        kvm->arch.nr_pmu_counters = new_n;
    ...
}

Because kvm_arm_pmu_get_max_counters() now returns 0, the bounds check fails.
set_pmcr() then leaves nr_pmu_counters at 0 without returning an error to
userspace.

Consequently, when set_pmreg() executes:

arch/arm64/kvm/sys_regs.c:set_pmreg() {
    ...
    u64 mask = kvm_pmu_accessible_counter_mask(vcpu);
    __vcpu_assign_sys_reg(vcpu, r->reg, val & mask);
}

The mask evaluates to only the cycle counter since nr_pmu_counters is 0.
This silently zeroes out the restored event counter bits for registers like
PMOVSSET_EL0, PMINTENSET_EL1, and PMCNTENSET_EL0.

Should the KVM API reject this out-of-order restoration sequence with an
error like -EINVAL, rather than silently discarding the VMM's restored
PMCR_EL0.N and event counter states?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702190421.420992-1-congkai@amazon.com?part=1