Following hpet_detach_channel(), IRQs may still occur: Ones may already
be in flight (both from before and after the last IRQ migration, i.e. on
possibly two distinct vectors targeting two different CPUs), and new ones
may still be raised as long as the channel is enabled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
RFC: Previously, when we still used "normal" IRQs, this would only work
     correctly if there's no shortage of vectors, i.e. if the original
     hpet_msi_set_affinity()'s call to set_desc_affinity() would succeed.
     With that changed the patch may not actually be of much help anymore
     (hence I've also dropped the Fixes: tag again); it was pretty useful
     prior to that.

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -241,8 +241,9 @@ again:
 static void cf_check hpet_interrupt_handler(int irq, void *data)
 {
     struct hpet_event_channel *ch = data;
+    unsigned int cpu = smp_processor_id();
 
-    this_cpu(irq_count)--;
+    per_cpu(irq_count, cpu)--;
 
     if ( !ch->event_handler )
     {
@@ -250,6 +251,9 @@ static void cf_check hpet_interrupt_hand
         return;
     }
 
+    if ( ch->cpu != cpu )
+        return;
+
     ch->event_handler(ch);
 }

On Thu, Oct 16, 2025 at 09:32:29AM +0200, Jan Beulich wrote:
> Following hpet_detach_channel(), IRQs may still occur: Ones may already
> be in flight (both from before and after the last IRQ migration, i.e. on
> possibly two distinct vectors targeting two different CPUs), and new ones
> may still be raised as long as the channel is enabled.

Description would need to be adjusted if nothing else, as it speaks
about two distinct vectors which is no longer possible after patch 3.

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

With the above adjusted:

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

Thanks, Roger.

On 17.10.2025 11:19, Roger Pau Monné wrote:
> On Thu, Oct 16, 2025 at 09:32:29AM +0200, Jan Beulich wrote:
>> Following hpet_detach_channel(), IRQs may still occur: Ones may already
>> be in flight (both from before and after the last IRQ migration, i.e. on
>> possibly two distinct vectors targeting two different CPUs), and new ones
>> may still be raised as long as the channel is enabled.
> 
> Description would need to be adjusted if nothing else, as it speaks
> about two distinct vectors which is no longer possible after patch 3.

Oh, right - dropping the parenthesized part.

>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> With the above adjusted:
> 
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, but as per the RFC remark: Do you then think this is actually
worthwhile despite what patch 3 does?

Jan

On Fri, Oct 17, 2025 at 11:57:28AM +0200, Jan Beulich wrote:
> On 17.10.2025 11:19, Roger Pau Monné wrote:
> > On Thu, Oct 16, 2025 at 09:32:29AM +0200, Jan Beulich wrote:
> >> Following hpet_detach_channel(), IRQs may still occur: Ones may already
> >> be in flight (both from before and after the last IRQ migration, i.e. on
> >> possibly two distinct vectors targeting two different CPUs), and new ones
> >> may still be raised as long as the channel is enabled.
> > 
> > Description would need to be adjusted if nothing else, as it speaks
> > about two distinct vectors which is no longer possible after patch 3.
> 
> Oh, right - dropping the parenthesized part.
> 
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > With the above adjusted:
> > 
> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Thanks, but as per the RFC remark: Do you then think this is actually
> worthwhile despite what patch 3 does?

I don't think it will hurt, but I also think this can possibly wait
after the code freeze, I don't see much win from doing it, and there's
a risk we might get it wrong.

Thanks, Roger.