On Mon, Nov 13, 2023 at 06:42:39PM +0100, Eric Auger wrote: > On Qualcomm Amberwing, some pmu-overflow-interrupt failures can be observed. > Although the even counter overflows, the interrupt is not seen as > expected on guest side. This happens in the subtest after "promote to 64-b" > comment. > > After analysis, the PMU overflow interrupt actually hits, ie. > kvm_pmu_perf_overflow() gets called and KVM_REQ_IRQ_PENDING is set, > as expected. However the PMCR.E is reset by the handle_exit path, at > kvm_pmu_handle_pmcr() before the next guest entry and > kvm_pmu_flush_hwstate/kvm_pmu_update_state subsequent call. > There, since the enable bit has been reset, kvm_pmu_update_state() does > not inject the interrupt into the guest. > > This does not seem to be a KVM bug but rather an unfortunate > scenario where the test disables the PMCR.E too closely to the > advent of the overflow interrupt. > > Since it looks like a benign and inlikely case, let's resize the number > of iterations to prevent the PMCR enable bit from being resetted > immediately at the same time as the actual overflow event. > > Also make pmu_stats volatile to prevent any optimizations. > > Eric Auger (2): > arm: pmu: Declare pmu_stats as volatile > arm: pmu-overflow-interrupt: Increase count values > > arm/pmu.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > -- > 2.41.0 > Merged into https://gitlab.com/kvm-unit-tests/kvm-unit-tests master Thanks, drew
