On Mon, 21 Sept 2026 at 08:44, Fuad Tabba <[email protected]> wrote: > > Hi folks, > > Two fixes for the same bug in three places: the next-tick calculation > for the generic timers, WFIT and WFET each treat a 64-bit overflow of > cval + offset (or timeout + offset) as a deadline beyond the counter's > wrap. Once CNTVOFF_EL2 (or CNTPOFF_EL2 for the physical timer) puts > the timer's view of the counter ahead of the physical count, that sum > overflows for every deadline still in the future and QEMU arms the > timer at INT64_MAX. The first site regressed in 8.2 (8d37a1425b99). > The WFxT sites have the same overflow test. > > The KVM arch_timer_edge_cases selftest, which sets the guest counter > to 2^59 - 1, hangs in every host mode on QEMU 11.0.0 and passes on > hardware under an nVHE host. With patch 1 it completes under nVHE and > pKVM hosts. Under a VHE host its physical-timer half still stops, on a > KVM bug in the same arithmetic (KVM programs cval + offset where the > timer compares unsigned). That fix goes to kvmarm separately. > > Each patch adds a tcg system test that fails before it and passes > after. > > Based on master (3b5d71cc36). > > Cheers, > /fuad > > Fuad Tabba (2): > target/arm: Fix next timer tick when the offset puts the count ahead > target/arm: Fix WFxT timeouts when the offset puts the count ahead
Thanks for the bugfixes and the clear explanation. Applied to target-arm.next, thanks. -- PMM
