Re: [PATCH v4 8/8] x86/HPET: don't arbitrarily cap delta in reprogram_hpet_evt_channel()

["Roger Pau Monné" <roger.pau@citrix.com>]

On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote:
> There's no reason to set an arbitrary upper bound of 10 seconds. We can
> simply set the comparator such that it'll take a whole cycle through all
> 32-bit values until the next interrupt would be raised. (For an extremely
> fast-running HPET [400 MHz and up] 10 seconds would also be too long.)
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v4: New.
> 
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -23,7 +23,6 @@
>  #include <asm/irq-vectors.h>
>  #include <asm/msi.h>
>  
> -#define MAX_DELTA_NS MILLISECS(10*1000)
>  #define MIN_DELTA_NS MICROSECS(20)
>  
>  #define HPET_EVT_USED_BIT    0
> @@ -162,10 +161,15 @@ static int reprogram_hpet_evt_channel(
>  
>      ch->next_event = expire;
>  
> -    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);
>  
> +    if ( delta > UINT32_MAX )
> +    {
> +        hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx));

Should Xen disable interrupts around this call to avoid unexpected
latency between the counter read and the comparator write?

Thanks, Roger.