Re: x86/irq: Unbreak interrupt affinity setting

[Alexander Graf]

On 26.08.20 23:47, David Laight wrote:
> From: David Laight
> > Sent: 26 August 2020 22:37
> >
> > From: Thomas Gleixner
> > > Sent: 26 August 2020 21:22
> > ...
> > > Moving interrupts on x86 happens in several steps. A new vector on a
> > > different CPU is allocated and the relevant interrupt source is
> > > reprogrammed to that. But that's racy and there might be an interrupt
> > > already in flight to the old vector. So the old vector is preserved until
> > > the first interrupt arrives on the new vector and the new target CPU. Once
> > > that happens the old vector is cleaned up, but this cleanup still depends
> > > on the vector number being stored in pt_regs::orig_ax, which is now -1.
> >
> > I suspect that it is much more 'racy' than that for PCI-X interrupts.
> > On the hardware side there is an interrupt disable bit, and address
> > and a value.
> > To raise an interrupt the hardware must write the value to the address.
> >
> > If the cpu needs to move an interrupt both the address and value
> > need changing, but the cpu wont write the address and value using
> > the same TLP, so the hardware could potentially write a value to
> > the wrong address.
> > Worse than that, the hardware could easily only look at the address
> > and value in the clocks after checking the interrupt is enabled.
> > So masking the interrupt immediately prior to changing the vector
> > info may not be enough.
> >
> > It is likely that a read-back of the mask before updating the vector
> > is enough.
>
> But not enough to assume you won't receive an interrupt after reading
> back that interrupts are masked.
>
> (I've implemented the hardware side for an fpga ...)

Do we actually care in this context? All we want to know here is whether 
a device (or irqchip in between) has actually noticed that it should 
post to a new vector. If we get interrupts on random other vectors in 
between, they would simply show up as spurious, no?

So I don't quite see where this patch makes the situation any worse than 
before.


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