On Fri, Dec 12, 2025 at 10:55:06PM +0000, Colton Lewis wrote:
Oliver Upton oupton@kernel.org 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".
Right, consider changing the shortlog to read more along the lines of "detect overflows for partitioned PMU" or similar.
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.
That's assuming the PMU is loaded eagerly which I thought we agreed it would not be.
Thanks, Oliver