On Fri, Jun 03, 2022 at 03:19:34PM +0200, Jan Beulich wrote: > On 21.04.2022 15:21, Roger Pau Monne wrote: > > Allow disabling (masking) IO-APIC pins set to edge trigger mode. This > > is required in order to safely migrate such interrupts between CPUs, > > as the write to update the IO-APIC RTE (or the IRTE) is not done > > atomically, > > For IRTE on VT-d we use cmpxchg16b if available (i.e. virtually always). > > > so there's a window where there's a mismatch between the > > destination CPU and the vector: > > > > (XEN) CPU1: No irq handler for vector b5 (IRQ -11, LAPIC) > > (XEN) IRQ10 a=0002[0002,0008] v=bd[b5] t=IO-APIC-edge s=00000030 > > I think this needs some further explanation, as we generally move > edge IRQs only when an un-acked interrupt is in flight (and hence > no further one can arrive).
A further one can arrive as soon as you modify either the vector or the destination fields of the IO-APIC RTE, as then the non-EOI'ed lapic vector is no longer there (because you have moved to a different destination or vector). This is the issue with updating the IO-APIC RTE using two separate writes: even when using interrupt remapping the IRTE cannot be atomically updated and there's a window where the interrupt is not masked, but the destination and vector fields are not in sync, because they reside in different parts of the RTE (destination is in the high 32bits, vector in the low 32bits part of the RTE). Thanks, Roger.
