Neither caller passes STIME_MAX, so (bogusly) handling the case isn't
necessary.

"Bogusly" because with 32-bit counters, writing 0 means on average half
the wrapping period until an interrupt would be raised, while of course
in extreme cases an interrupt would be raised almost right away.

Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: Drop the code instead of adjusting it.

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel(
 
     ch->next_event = expire;
 
-    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));
-        return 0;
-    }
-
     delta = min_t(int64_t, delta, MAX_DELTA_NS);
     delta = max_t(int64_t, delta, MIN_DELTA_NS);
     delta = ns2ticks(delta, ch->shift, ch->mult);

On Mon, Nov 17, 2025 at 03:39:03PM +0100, Jan Beulich wrote:
> Neither caller passes STIME_MAX, so (bogusly) handling the case isn't
> necessary.
> 
> "Bogusly" because with 32-bit counters, writing 0 means on average half
> the wrapping period until an interrupt would be raised, while of course
> in extreme cases an interrupt would be raised almost right away.
> 
> Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

> ---
> v3: Drop the code instead of adjusting it.
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel(
>  
>      ch->next_event = expire;
>  
> -    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));
> -        return 0;
> -    }

I wouldn't mind if you replaced this with an ASSERT(expire != STIME_MAX);

Thanks, Roger.

On 22.01.2026 10:03, Roger Pau Monné wrote:
> On Mon, Nov 17, 2025 at 03:39:03PM +0100, Jan Beulich wrote:
>> Neither caller passes STIME_MAX, so (bogusly) handling the case isn't
>> necessary.
>>
>> "Bogusly" because with 32-bit counters, writing 0 means on average half
>> the wrapping period until an interrupt would be raised, while of course
>> in extreme cases an interrupt would be raised almost right away.
>>
>> Amends: aa42fc0e9cd9 ("cpuidle: remove hpet access in hpet_broadcast_exit")
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

>> --- a/xen/arch/x86/hpet.c
>> +++ b/xen/arch/x86/hpet.c
>> @@ -162,13 +162,6 @@ static int reprogram_hpet_evt_channel(
>>  
>>      ch->next_event = expire;
>>  
>> -    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));
>> -        return 0;
>> -    }
> 
> I wouldn't mind if you replaced this with an ASSERT(expire != STIME_MAX);

Hmm, yes, can do.

Jan