On 26.08.20 20:53, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 20:30, Thomas Gleixner wrote:
And it does not solve the issue that we abuse orig_ax which Andy mentioned.
Ha! After staring some more, it's not required at all, which is the most elegant solution.
The vector check is pointless in that condition because there is never a condition where an interrupt is moved from vector A to vector B on the same CPU.
That's a left over from the old allocation model which supported multi-cpu affinities, but this was removed as it just created trouble for no real benefit.
Today the effective affinity which is a single CPU out of the requested affinity. If an affinity mask change still contains the current target CPU then there is no move happening at all. It just stays on that vector on that CPU.
Thanks,
tglx
--- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -909,7 +909,7 @@ void send_cleanup_vector(struct irq_cfg __send_cleanup_vector(apicd); }
-static void __irq_complete_move(struct irq_cfg *cfg, unsigned vector) +void irq_complete_move(struct irq_cfg *cfg) { struct apic_chip_data *apicd;
@@ -917,15 +917,10 @@ static void __irq_complete_move(struct i if (likely(!apicd->move_in_progress)) return;
if (vector == apicd->vector && apicd->cpu == smp_processor_id())
if (apicd->cpu == smp_processor_id()) __send_cleanup_vector(apicd);-void irq_complete_move(struct irq_cfg *cfg) -{
__irq_complete_move(cfg, ~get_irq_regs()->orig_ax);-}
- /*
*/
- Called from fixup_irqs() with @desc->lock held and interrupts disabled.
As expected, this also fixes the issue at hand. Do you want to send a real patch? :)
Tested-by: Alexander Graf graf@amazon.com
Alex
Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879