Messages in this thread | | | From | "Tian, Kevin" <> | Subject | RE: [PATCH v2 10/13] x86/irq: Extend checks for pending vectors to posted interrupts | Date | Fri, 12 Apr 2024 09:25:57 +0000 |
| |
> From: Jacob Pan <jacob.jun.pan@linux.intel.com> > 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.
| |