With 32-bit counters, writing 0 means on average half the wrapping period
until an interrupt would be raised. Yet of course in extreme cases an
interrupt would be raised almost right away. Write the present counter
value instead, to make the timeout predicatbly a full wrapping period.

Fixes: e862b83e8433 ("CPUIDLE: Avoid remnant HPET intr while force hpetbroadcast")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Actually - can't we just disable the channel instead of setting a "long"
timeout? Of course we'd then also need to enable it a few lines down. Yet
in turn we could then remove the enabling from set_channel_irq_affinity().

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -165,7 +165,7 @@ static int reprogram_hpet_evt_channel(
     if ( expire == STIME_MAX )
     {
         /* We assume it will take a long time for the timer to wrap. */
-        hpet_write32(0, HPET_Tn_CMP(ch->idx));
+        hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx));
         return 0;
     }

On Mon, Oct 20, 2025 at 01:21:18PM +0200, Jan Beulich wrote:
> With 32-bit counters, writing 0 means on average half the wrapping period
> until an interrupt would be raised. Yet of course in extreme cases an
> interrupt would be raised almost right away. Write the present counter
> value instead, to make the timeout predicatbly a full wrapping period.
> 
> Fixes: e862b83e8433 ("CPUIDLE: Avoid remnant HPET intr while force hpetbroadcast")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Maybe I'm missing a path, but are there any callers that still pass
STIME_MAX to reprogram_hpet_evt_channel()?

hpet_broadcast_exit() no longer explicitly passes STIME_MAX like it
did in e862b83e8433, and then the per-cpu timer_deadline variable is
not set to STIME_MAX either in timer_softirq_action().

Thanks, Roger.

On 21.10.2025 16:21, Roger Pau Monné wrote:
> On Mon, Oct 20, 2025 at 01:21:18PM +0200, Jan Beulich wrote:
>> With 32-bit counters, writing 0 means on average half the wrapping period
>> until an interrupt would be raised. Yet of course in extreme cases an
>> interrupt would be raised almost right away. Write the present counter
>> value instead, to make the timeout predicatbly a full wrapping period.
>>
>> Fixes: e862b83e8433 ("CPUIDLE: Avoid remnant HPET intr while force hpetbroadcast")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Maybe I'm missing a path, but are there any callers that still pass
> STIME_MAX to reprogram_hpet_evt_channel()?
> 
> hpet_broadcast_exit() no longer explicitly passes STIME_MAX like it
> did in e862b83e8433, and then the per-cpu timer_deadline variable is
> not set to STIME_MAX either in timer_softirq_action().

Good point. It was me missing the fact that "expire" is an unaltered function
argument; I (blindly) assumed it would be calculated there. So yes, that
check can simply go away.

Jan

On 20.10.2025 13:21, Jan Beulich wrote:
> With 32-bit counters, writing 0 means on average half the wrapping period
> until an interrupt would be raised. Yet of course in extreme cases an
> interrupt would be raised almost right away. Write the present counter
> value instead, to make the timeout predicatbly a full wrapping period.
> 
> Fixes: e862b83e8433 ("CPUIDLE: Avoid remnant HPET intr while force hpetbroadcast")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Whereas here I'm sorry: I screwed up and left the 4.21 tag in place.

Jan