On Fri, 7 Feb 2025 at 18:29, Alex Bennée <alex.ben...@linaro.org> wrote: > > Richard Henderson <richard.hender...@linaro.org> writes: > > > On 2/7/25 07:45, Peter Maydell wrote: > >> This is where things go wrong -- icount_start_warp_timer() > >> notices that all CPU threads are currently idle, and > >> decides it needs to warp the timer forwards to the > >> next deadline, which is at the end of time -- INT64_MAX. > >> But once timer_mod_ns() returns, the generic timer code > >> is going to raise an interrupt (this goes through the GIC > >> code and comes back into the CPU which calls cpu_interrupt()), > >> so we don't want to warp the timer at all. The clock should > >> stay exactly at the value it has and the CPU is going to > >> have more work to do. > >> How is this supposed to work? Shouldn't we only be doing > >> the "start moving the icount forward to the next deadline" > >> once we've completed all the "run timers and AIO stuff" that > >> icount_handle_deadline() triggers, not randomly in the middle > >> of that when this timer callback or some other one might do > >> something to trigger an interrupt? > > > > I don't understand timer warping at all. And you're right, it doesn't > > seem like this should happen outside of a specific point in the main > > loop. > > This has come up before - and the conclusion was we don't know what > sleep=on/off is meant to mean. If the processor is asleep and there are > no timers to fire then nothing will happen. > > It was off-list though: > > Subject: Re: qemu-system-aarch64 & icount behavior
No, that was a different situation. That thread was about when there genuinely is nothing to do (all CPUs asleep and no timers active) for the rest of the life of the simulation. The bug in this thread is that icount incorrectly prematurely decides it should warp the timer forwards, when in fact there is going to be something the CPU should be doing right now (i.e. responding to the interrupt the timer callback is about to raise). It becomes very obvious when there's no other timer callback, because the place that icount incorrectly warps us to is end-of-time, but I'm pretty sure that even when there is another timer active icount will still be wrongly warping time -- it will just be less obvious because the interrupt gets incorrectly delayed to whatever that subsequent timer callback time is, rather than forever. thanks -- PMM
