Re: [PATCH] target/arm/helper: Fix timer interrupt masking when HCR_EL2.E2H == 0

[Richard Henderson]

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.

> ... But I don't think there's any reason why
> timer callbacks should be obliged to reprogram their timers
> last, and in any case you can imagine scenarios where there
> are multiple timer callbacks for different timers and it's
> only the second timer that raises an interrupt...

Agreed.


r~