Re: [PATCH 16/21] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Host perf event overflows corrupt the virtual PMU state of running vCPUs.
- [High] KVM traps PMOVSCLR_EL0 but fails to read live hardware state, breaking guest PMU polling.
--

commit 18a5ac7857cf364463b827796f49cf7c00c6ef08
Author: Colton Lewis <coltonlewis@google.com>

perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters

Because ARM hardware is not yet capable of direct PPI injection into
guests, guest counters will still trigger interrupts that need to be
handled by the host PMU interrupt handler. Clear the overflow flags in
hardware to handle the interrupt as normal, but update the virtual
overflow register for later injecting the interrupt into the guest.

> diff --git a/arch/arm64/kvm/pmu-direct.c b/arch/arm64/kvm/pmu-direct.c
> index bb1f3dca03869..64f40cfb31012 100644
> --- a/arch/arm64/kvm/pmu-direct.c
> +++ b/arch/arm64/kvm/pmu-direct.c
> @@ -405,3 +405,25 @@ void kvm_pmu_set_guest_owned(struct kvm_vcpu *vcpu)

[ ... ]

> +/**
> + * kvm_pmu_handle_guest_irq() - Record IRQs in guest counters
> + * @pmu: PMU to check for overflows
> + * @pmovsr: Overflow flags reported by driver
> + *
> + * Set overflow flags in guest-reserved counters in the VCPU register
> + * for the guest to clear later.
> + */
> +void kvm_pmu_handle_guest_irq(struct arm_pmu *pmu, u64 pmovsr)
> +{
> +	struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
> +	u64 mask = kvm_pmu_guest_counter_mask(pmu);
> +	u64 govf = pmovsr & mask;
> +
> +	write_pmovsclr(govf);
> +
> +	if (!vcpu)
> +		return;
> +
> +	__vcpu_rmw_sys_reg(vcpu, PMOVSSET_EL0, |=, govf);

[Severity: Critical]
Can host perf event overflows corrupt the virtual pmu state of running vCPUs?

When the host pmu is partitioned, the host perf subsystem is allowed to use
the guest partition counters (0..hpmn) whenever the currently running vCPU
does not own the pmu (e.g., vCPUs using the emulated pmu).

However, kvm_pmu_host_counter_mask() unconditionally excludes these
counters from the host's clear mask. When a host event on these counters
overflows, the host irq handler leaves the hardware flag set and passes the
overflow to kvm_pmu_handle_guest_irq().

This code blindly applies the host overflow to the currently running vCPU's
PMOVSSET_EL0 software state without verifying if the vCPU actually owns
the pmu partition:

    vcpu->arch.pmu.access == VCPU_PMU_ACCESS_GUEST_OWNED

Could this corrupt the virtual pmu state and inject spurious overflows
into innocent VMs?

> +}
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index c187397134990..6ab15a5209608 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -774,16 +774,15 @@ static void armv8pmu_disable_event_irq(struct perf_event *event)
>  	armv8pmu_disable_intens(BIT(event->hw.idx));
>  }
>  
> -static u64 armv8pmu_getreset_flags(void)
> +static u64 armv8pmu_getovf_flags(void)
>  {
>  	u64 value;
>  
>  	/* Read */
>  	value = read_pmovsclr();
>  
> -	/* Write to clear flags */
> -	value &= ARMV8_PMU_CNT_MASK_ALL;
> -	write_pmovsclr(value);
> +	/* Only report interrupt enabled counters. */
> +	value &= read_pmintenset();

[Severity: High]
Does masking out overflow flags for counters without interrupts enabled break
guest pmu polling?

KVM unconditionally traps guest accesses to PMOVSCLR_EL0 and PMOVSSET_EL0
(via FGT HDFGRTR_EL2_PMOVS) to prevent the guest from seeing host counter
overflows. However, the trap handlers (pmu_reg_read and pmu_reg_write
in arch/arm64/kvm/sys_regs.c) only interact with KVM's software shadow
state and ignore the live hardware pmovsclr_el0 register for guest-owned
counters.

Since this masks hardware overflows with read_pmintenset(), counters with
interrupts disabled will never trigger the host irq handler to sync the
shadow state.

Consequently, will a guest polling for overflows with pmu interrupts disabled
loop infinitely reading stale zeros and miss the overflow events entirely?

>  
>  	return value;
>  }

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