You copied the Doc URL to your clipboard.

LPI caching

If LPI support is configured, the GIC-600 supports a single LPI cache per chip.

The LPI cache is two-way set associative based on the lowest bits of the LPI INTID, and stores LPI properties from the LPI Property table. The relevant set is checked for valid properties as each LPI arrives in the system.

The cache is fully associative for pending LPIs, which means that the LPI system fills almost all lines in the cache before sending anything to the Pending tables. The GIC-600 is not optimized for collating LPIs that have the same INTID. However the system is designed to reorder and sort the cache over time. In some circumstances, this can cause duplicated interrupts to not be collated efficiently. However, the reduced use of the Pending table, results in better latency bounds under load.

This method of caching means that priorities are associated with an incoming LPI and remain with it until it is serviced. Changes in the LPI Property table are not accepted by the GIC until the relevant INV and SYNC commands are executed through an ITS, GICR_INVLPIR or GICR_INVALLR.

The GIC-600 considers priority and enable when choosing data to retain in the cache. However, pending interrupts always take priority over interrupts that are not pending, so there is no guarantee that the highest priority interrupt data always remains stored in the cache.

Was this page helpful? Yes No