Re: [PATCH v5 21/24] KVM: arm64: Inject recorded guest interrupts

[Colton Lewis]

Oliver Upton <oupton@xxxxxxxxxx> writes:

> In no situation should KVM be injecting a "recorded" IRQ. The overflow
> condition of the PMU is well defined in the architecture and we should
> implement *exactly* that.

When I say "record" I just meant "updating the virtual overflow register
to reflect an overflow".

Do you think I'm not implementing the condition correctly in
kvm_pmu_part_overflow_status()?

> On Tue, Dec 09, 2025 at 08:51:18PM +0000, Colton Lewis wrote:
> > +/**
> > + * kvm_pmu_part_overflow_status() - Determine if any guest counters  
> > have overflowed
> > + * @vcpu: Ponter to struct kvm_vcpu
> > + *
> > + * Determine if any guest counters have overflowed and therefore an
> > + * IRQ needs to be injected into the guest.
> > + *
> > + * Return: True if there was an overflow, false otherwise
> > + */
> > +bool kvm_pmu_part_overflow_status(struct kvm_vcpu *vcpu)
> > +{
> > +	struct arm_pmu *pmu = vcpu->kvm->arch.arm_pmu;
> > +	u64 mask = kvm_pmu_guest_counter_mask(pmu);
> > +	u64 pmovs = __vcpu_sys_reg(vcpu, PMOVSSET_EL0);
> > +	u64 pmint = read_pmintenset();
> > +	u64 pmcr = read_pmcr();

> How do we know that the vPMU has been loaded on the CPU at this point?

Because this is only called by kvm_pmu_update_state which is only called
by kvm_pmu_update_state <- kvm_pmu_{flush,sync}_hwstate <-
kvm_arch_vcpu_ioctl_run after a vcpu_load.

> > +
> > +	return (pmcr & ARMV8_PMU_PMCR_E) && (mask & pmovs & pmint);
> > +}

> I'd rather reuse kvm_pmu_overflow_status(), relying on the accessors to
> abstract away the implementation / location of the guest PMU context.

Agreed on making some generic accessors.

> Thanks,
> Oliver