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 <[email protected]> --- 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); }
