Re: [PATCH v9 17/22] KVM: arm64: Implement lazy PMU context swaps

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: arm64: PMU hardware permanently frozen after live migration
--

commit 458afe99983a6c37492623080fcc934e4e368118
Author: Colton Lewis <coltonlewis@google.com>

KVM: arm64: Implement lazy PMU context swaps
    
This patch implements lazy PMU context swapping to avoid the overhead of
reserving hardware counters on every vCPU load and put. It introduces per-vCPU
PMU ownership tracking, transitioning to GUEST_OWNED only when the guest
actively enables PMU counters or interrupts.

> diff --git a/arch/arm64/kvm/pmu-direct.c b/arch/arm64/kvm/pmu-direct.c
> --- a/arch/arm64/kvm/pmu-direct.c
> +++ b/arch/arm64/kvm/pmu-direct.c
> @@ -336,7 +342,9 @@ void kvm_pmu_load(struct kvm_vcpu *vcpu)
>  	 * If we aren't guest-owned then we know the guest isn't using
>  	 * the PMU anyway, so no need to bother with the swap.
>  	 */
> -	if (!kvm_pmu_is_partitioned(vcpu->kvm))
> +	if (!kvm_pmu_is_partitioned(vcpu->kvm) ||
> +	    kvm_pmu_get_access(vcpu) != VCPU_PMU_ACCESS_GUEST_OWNED ||
> +	    vcpu->arch.pmu.loaded_on_cpu)

[Severity: High]
Does this logic cause the PMU hardware to remain permanently frozen after a
live migration?

When userspace restores the PMU state via KVM_SET_ONE_REG (which routes
through set_pmcr() and set_pmreg() in arch/arm64/kvm/sys_regs.c), it
bypasses pmu_reg_write() and assigns the system registers directly. Because
the state is never transitioned to VCPU_PMU_ACCESS_GUEST_OWNED on this
restore path, it remains VCPU_PMU_ACCESS_FREE.

Later, when kvm_pmu_load() runs, it aborts early due to the access state
being FREE, meaning the physical counters are never configured or started.
Although kvm_pmu_part_overflow_status() acts as a fallback to catch state
restoration, it explicitly requires an overflow to be pending:

arch/arm64/kvm/pmu-direct.c:kvm_pmu_part_overflow_status() {
    ...
    if (overflow && kvm_pmu_get_access(vcpu) == VCPU_PMU_ACCESS_FREE)
        kvm_pmu_set_guest_owned(vcpu);
    ...
}

If the guest is migrated while actively counting but no overflow is pending,
the counters will never tick, will never overflow, and this fallback will
never trigger. Could the restore paths be updated to ensure the ownership
transitions correctly?

>  		return;
>  
>  	preempt_disable();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924172928.2110956-1-coltonlewis@google.com?part=17