Oliver Upton <[email protected]> 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
