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 Thu, Jan 22, 2026 at 11:35:06AM +0100, Jan Beulich wrote:
> On 22.01.2026 11:23, Roger Pau Monné wrote:
> > On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote:
> >> @@ -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?
> 
> Such latency could then still arise, due NMI or SMI. What's your underlying
> concern here?

For NMI or SMI there isn't much we can do.  I guess this is much less
of a concern here than it is in hpet_next_event(), given the next
event is expected to be after a full HPET counter period.  One of
those events taking a full HPET counter period overlap would make a
lot of others things explode.

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

Thanks, Roger.