On 03.06.2022 16:53, Roger Pau Monné wrote: > 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).
Right - this is what I'm asking you to spell out in the description. Jan > 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. >
