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@xxxxxxxxxx>
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
