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 <[email protected]> > --- > 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.
