Visible to Intel only — GUID: hpv1687910105153
Ixiasoft
Visible to Intel only — GUID: hpv1687910105153
Ixiasoft
3.6.3. 1494863: SPI recall failure without subsequent trigger
Description
If an interrupt is identified as one of the top priority enabled interrupts for a CPU and is sent to the target cache, then there is a single-cycle window where if the interrupt is reprogrammed then the recall requirement is logged but not performed until the next external trigger.
The triggers can be any of:
- Activation, release, or deactivation of any SPI.
- A state change on any SPI signal.
- Register programming or a CPU group enable change.
Conditions
Impact
There are two implications:
- If software changes a GICD_IROUTER register, then the ACE-Lite slave interface might not respond until the next trigger occurs or the CPU services the interrupt.
- If software programs registers other than ICENABLER, then the duration when the GIC uses old programming might extend until after the next trigger. The GIC does not use old programming more than once, or go back to old programing once it uses the new programming.
Workaround
Disable SPIs by writing to ICENABLER<n> before reprogramming them, especially if rerouting them by programming GICD_IROUTER.
This workaround ensures that all reprogramming of an SPI is atomic, and is the standard behavior of the Linux driver.
Category
Category B