On 20.10.2025 13:18, Jan Beulich wrote:
> @@ -526,6 +524,8 @@ static void hpet_detach_channel(unsigned
> spin_unlock_irq(&ch->lock);
> else if ( (next = cpumask_first(ch->cpumask)) >= nr_cpu_ids )
> {
> + hpet_disable_channel(ch);
> + ch->next_event = STIME_MAX;
> ch->cpu = -1;
> clear_bit(HPET_EVT_USED_BIT, &ch->flags);
> spin_unlock_irq(&ch->lock);
Now that I have everything else working, I thought I'd look into where the
excess IRQs come from on Intel hardware. Since my earlier experiment with
making conditional the write in hpet_enable_channel() / hpet_msi_unmask()
had failed, I was misguided into assuming some more complex logic in their
HPETs. It now appears to be as simple as I initially suspected: It's 0 -> 1
transitions of the ENABLE bit which cause immediate IRQs. And the reason
why the removal of the mask/unmask pairs in patch 2 weren't (sufficiently)
helpful is above: We better wouldn't disable the channels, to avoid said
(mis-)feature. Instead I'm now intending to merely write a long timeout
value here, along the lines of what I did in this version (code there fully
dropped in v3 though) in patch 8.
Jan
