> From: Jacob Pan <jacob.jun.pan@xxxxxxxxxxxxxxx> > Sent: Saturday, April 6, 2024 6:31 AM > > During interrupt affinity change, it is possible to have interrupts delivered > to the old CPU after the affinity has changed to the new one. To prevent lost > interrupts, local APIC IRR is checked on the old CPU. Similar checks must be > done for posted MSIs given the same reason. > > Consider the following scenario: > Device system agent iommu memory > CPU/LAPIC > 1 FEEX_XXXX > 2 Interrupt request > 3 Fetch IRTE -> > 4 ->Atomic Swap PID.PIR(vec) > Push to Global > Observable(GO) > 5 if (ON*) > i done;* there is a stray 'i' > else > 6 send a notification -> > > * ON: outstanding notification, 1 will suppress new notifications > > If the affinity change happens between 3 and 5 in IOMMU, the old CPU's > posted > interrupt request (PIR) could have pending bit set for the vector being moved. how could affinity change be possible in 3/4 when the cache line is locked by IOMMU? Strictly speaking it's about a change after 4 and before 6.
