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 ...) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
