Chapter 1: Introduction

This chapter provides an introduction to the GIC architecture. It provides an overview of the GIC architecture, and the features that are new to the architecture. It also provides definitions of the terminology that this document uses. It contains the following sections:

• About the Generic Interrupt Controller (GIC) .

• Terminology .

• Supported configurations and compatibility . 1.1 About the Generic Interrupt Controller (GIC)

1.1 About the Generic Interrupt Controller (GIC)

The GICv3 architecture is designed to operate with Armv8-A and Armv8-R compliant processing elements , PEs.

The Generic Interrupt Controller (GIC) architecture defines:

• The architectural requirements for handling all interrupt sources for any PE connected to a GIC.

• A common interrupt controller programming interface applicable to uniprocessor or multiprocessor systems.

The GIC is an architected resource that supports and controls interrupts. It provides:

• Registers for managing interrupt sources, interrupt behavior, and the routing of interrupts to one or more PEs.

• Support for:

  • The Armv8 architecture.

• Locality-specific Peripheral Interrupts (LPIs).

  • Private Peripheral Interrupts (PPIs).

• Software Generated Interrupts (SGIs).

  • Shared Peripheral Interrupts (SPIs).

  • Interrupt masking and prioritization.

  • Uniprocessor and multiprocessor systems.

• Wakeup events in power management environments.

For each PE, the GIC architecture describes how IRQ and FIQ interrupts can be generated from different types of interrupts within the system. The Armv8-A Exception model describes how the PE handles these IRQ and FIQ interrupts.

Interrupt handling also depends on other aspects of the Armv8 architecture, such as the Security state and support for virtualization. The Arm architecture provides two Security states, each with an associated physical memory address space:

• Secure state.

• Non-secure state.

The GIC architecture supports the routing and handling of interrupts that are associated with both Security states. See Interrupt grouping and security for more information.

The GIC architecture supports the Armv8 model for handling virtual interrupts that are associated with a virtual machine , VM. A virtualized system has:

• A hypervisor that must include a component executing at EL2, that is responsible for switching between VMs.

• Several VMs executing at EL1.

• Applications executing at EL0 on a VM.

For more information about the Armv8 architecture, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile . For more information about VMs, see About GIC support for virtualization .

This specification defines version 3.0, version 3.1, version 3.2 (collectively GICv3), version 4.0, and version 4.1 (collectively GICv4.1) of the GIC architecture. Version 2.0 (GICv2) is only described in terms of the GICv3 optional support for legacy operation, see GICv3 with legacy operation . For detailed information about the GICv2 architecture, see the Arm[®] Generic Interrupt Controller, Architecture version 2.0, Architecture Specification .

Note Because GICv4 is an extension of GICv3.0 and GICv3.1, all references to GICv3 in this manual apply equally to GICv4, unless explicitly indicated otherwise. Any changes to the architecture specification for GICv4.1 are indicated accordingly.

1.1.1 Changes to the GIC architecture from GICv2

GIC scalability

The GICv2 architecture only supports a maximum of eight PEs, and so has features that do not scale to a large system. GICv3 addresses this by changing the mechanism by which interrupts are routed, called affinity routing , and by introducing a new component to the interrupt distribution, called a Redistributor . See Chapter 3 GIC Partitioning for more information.

Affinity routing for a Security state is enabled by setting GICD_CTLR.ARE_S or GICD_CTLR.ARE_NS to 1.

Interrupt grouping

Interrupt grouping is the mechanism that is used by GICv3 to align interrupt handling with the Armv8 Exception model:

• Group 0 physical interrupts are expected to be handled at the highest implemented Exception level.

• Secure Group 1 physical interrupts are expected to be handled at Secure EL1 or EL2.

• Non-secure Group 1 physical interrupts are excepted to be handled at Non-secure EL2 in systems using virtualization, or at Non-secure EL1 in systems not using virtualization.

These interrupt groups can be mapped onto the Armv8 FIQ and IRQ signals as described in Interrupt grouping , using configuration bits from the Armv8 architecture and the configuration bits within the GICv3 architecture.

In GICv3, interrupt grouping supports:

• Configuring each interrupt as Group 0, Secure Group 1, or Non-secure Group 1.

• Signaling Group 0 physical interrupts to the target PE using the FIQ exception request.

• Signaling Group 1 physical interrupts to the target PE in a manner that allows them to be handled using the IRQ handler in their own Security state. The exact handling of Group 1 interrupts depends on the current Exception level and Security state, as described in Chapter 4 Physical Interrupt Handling and Prioritization .

• A unified scheme for handling the priority of Group 0 and Group 1 interrupts.

Interrupt Translation Service (ITS)

The Interrupt Translation Service, ITS, provides functionality that allows software to control how interrupts that are forwarded to the ITS are translated into:

• Physical interrupts, in GICv3 and GICv4.

• Virtual interrupts, in GICv4 only.

The ITS also allows software to determine the target Redistributor for a translated interrupt. Software can control the ITS through a command interface and associated table-based structures in memory. The outputs of the Interrupt Translation Service (ITS) are always LPIs, which are a form of message-based interrupt. See The Interrupt Translation Service .

Locality-specific Peripheral Interrupts (LPIs)

LPIs are a new class of interrupt that significantly extends the interrupt ID space that the GIC can handle. LPIs are optional, and, if implemented, can be generated and supported by an Interrupt Translation Service, ITS. See LPIs .

Software Generated Interrupts (SGIs)

With the ability of GICv3 to support large-scale systems, the context of an SGI is modified and no longer includes the identity of the source PE. See Software Generated Interrupts .

Note

The original SGI format is only available in GIC implementations that support legacy operation.

Shared Peripheral Interrupts (SPIs)

A new set of registers in the Distributor is added to support the setting and clearing of message-based SPIs. See Shared Peripheral Interrupts .

System register interface

This interface uses System register instructions in an Armv8-A or Armv8-R PE to provide a closely-coupled interface for the CPU interface registers. This interface is used for registers that are associated directly with interrupt handling and priority masking to minimize access latency. For virtualization, the registers that are accessed in this manner include both the registers that are accessed by a VM interrupt handler, and the registers that forward virtual interrupts from a hypervisor to a VM. All other registers are memory-mapped.

For AArch64 state, access to the System register interface is enabled by the following settings:

• ICC_SRE_EL1.SRE == 1.

• • ICC_SRE_EL2.SRE == 1. • ICC_SRE_EL3.SRE == 1.

For AArch32 state, access to the System register interface is enabled by the following settings: • ICC_SRE.SRE == 1. • ICC_HSRE.SRE == 1. • ICC_MSRE.SRE == 1.

Other behavior, which is backwards compatible with GICv2, is described in Chapter 14 Legacy Operation and Asymmetric Configurations .

Note

In a GIC that supports legacy operation, memory-mapped access is available for all architected GIC registers.

Unless indicated otherwise, this manual describes the GICv3 architecture in a system with affinity routing, System register access, and two Security states, enabled. This means that:

• GICD_CTLR.ARE_NS == 1.

• • GICD_CTLR.ARE_S == 1. • GICD_CTLR.DS == 0.

For operation in AArch64 state:

• ICC_SRE_EL1.SRE == 1, for both the Secure and the Non-secure copy of this register.

• ICC_SRE_EL2.SRE == 1.

• ICC_SRE_EL3.SRE == 1.

For operation in AArch32 state:

• ICC_SRE.SRE == 1.

• ICC_HSRE.SRE == 1.

• ICC_MSRE.SRE == 1.

From GICv3 onwards, legacy operation with the ARE and SRE control bits set to 0 is deprecated, and removed if the PE implements Secure EL2. See Chapter 14 Legacy Operation and Asymmetric Configurations for more information about legacy operation.

Changes specific to GICv3.1

GICv3.1 adds support for Memory Partitioning and Monitoring, an extended SPI range, an extended PPI range, and support for Secure EL2.

Changes specific to GICv3.2

GICv3.2 adds support for Armv8-R AArch64.

Changes specific to GICv4

GICv4 adds support for the direct injection of virtual interrupts to a VM, without involving the hypervisor. Direct injections are only supported by systems that implement at least one ITS that translates interrupts into LPIs.

Changes specific to GICv4.1

GICv4.1 extends direct injection support to also handle virtual SGIs. GICv4.1 changes the way some GICv4 data structures are handled.

1.2 Terminology

The architecture descriptions in this manual use the same terminology that is used for the Armv8 architecture. For more information about this terminology, see the introduction to Part A of the Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

In addition, the AArch64 System register names are used where appropriate, in preference to listing both the AArch32 and AArch64 System register names. The EL x suffix on the AArch64 register name indicates the lowest Exception level at which the register can be accessed. The individual AArch64 System register descriptions contain a reference to the AArch32 System register that provides the same functionality.

The following sections define the architectural terms used in this manual:

• Interrupt types .

• Interrupt states .

• Models for handling interrupts .

• Additional terms .

1.2.1 Interrupt types

A device that implements the GIC architecture can control peripheral interrupts . Peripheral interrupts are typically asserted by a physical signal to the GIC. The GIC architecture defines the following types of peripheral interrupt:

Locality-specific Peripheral Interrupt (LPI)

An LPI is a targeted peripheral interrupt that is routed to a specific PE within the affinity hierarchy:

• LPIs are always Non-secure Group 1 interrupts, in a system where two Security states are enabled.

• LPIs have edge-triggered behavior.

• LPIs can be routed using an ITS.

• LPIs do not have an active state, and therefore do not require explicit deactivation.

• LPIs are always message-based interrupts.

See LPIs for more information.

Private Peripheral Interrupt (PPI)

This is a peripheral interrupt that targets a single, specific PE, and different PEs can use the same interrupt number to indicate different events:

• PPIs can be Group 0 interrupts, Secure Group 1 interrupts, or Non-secure Group 1 interrupts.

• PPIs can support either edge-triggered or level-sensitive behavior.

• PPIs are never routed using an ITS.

• PPIs have an active state and therefore require explicit deactivation.

Note

Commonly, it is expected that PPIs are used by different instances of the same interrupt source on each PE, thereby allowing a common interrupt number to be used for PE-specific events, such as the interrupts from a private timer.

Shared Peripheral Interrupt (SPI)

This is a peripheral interrupt that the Distributor can route to a specified PE that can handle the interrupt, or to a PE that is one of a group of PEs in the system that has been configured to accept this type of interrupt:

• SPIs can be Group 0 interrupts, Secure Group 1 interrupts, or Non-secure Group 1 interrupts.

• SPIs can support either edge-triggered or level-sensitive behavior.

• SPIs are never routed using an ITS.

• SPIs have an active state and therefore require explicit deactivation.

See Shared Peripheral Interrupts for more information. For more information about the Distributor, see Chapter 3 GIC Partitioning .

Software Generated Interrupt (SGI)

SGIs are typically used for inter-processor communication, and are generated by a write to an SGI register in the GIC:

• SGIs can be Group 0 interrupts, Secure Group 1 interrupts, or Non-secure Group 1 interrupts.

• SGIs have edge-triggered behavior.

• SGIs are never routed using an ITS.

• SGIs have an active state and therefore require explicit deactivation.

See Software Generated Interrupts for more information.

An interrupt that is edge-triggered has the following property:

• It is asserted on detection of a rising edge of an interrupt signal and then, regardless of the state of the signal, remains asserted until the interrupt is acknowledged by software.

For information about edge-triggered message-based interrupts, see Message-based interrupt.

An interrupt that is level-sensitive has the following properties:

• It is asserted whenever the interrupt signal level is active, and deasserted whenever the level is not active.

• It is explicitly deasserted by software.

1.2.2 Interrupt states

The following states apply at each interface between the GIC and a connected PE:

Inactive An interrupt that is not active or pending. Pending An interrupt that is recognized as asserted in hardware, or generated by software, and is waiting to be handled by the target PE.

Active An interrupt that has been acknowledged by a PE and is being handled, so that another assertion of the same interrupt is not presented as an interrupt to a PE, until the initial interrupt is no longer active.

LPIs do not have an active state, and transition to the inactive state on being acknowledged by a PE.

Active and pending An interrupt that is active from one assertion of the interrupt, and is pending from a subsequent assertion.

LPIs do not have an active and pending state, and transition to the inactive state on being acknowledged by a PE.

The GIC maintains state for each supported interrupt. The state machine defines the possible transitions between interrupt states, and, for each interrupt type, the conditions that cause a transition. See Interrupt handling state machine for more information.

1.2.3 Models for handling interrupts

In a multiprocessor implementation, the following models exist for handling interrupts:

Targeted distribution model

This model applies to all PPIs and to all LPIs. It also applies to:

• SPIs during non-legacy operation, if GICD_IROUTER.Interrupt_Routing_Mode == 0.

• During legacy operation, when GICD_CTLR.ARE_* == 0, if only one bit in the appropriate GICD_ITARGETSR field == 1.

A target PE that has been specified by software receives the interrupt.

Targeted list model

This model applies to SGIs only. Multiple PEs receive the interrupt independently. When a PE acknowledges the interrupt, the interrupt pending state is cleared only for that PE. The interrupt remains pending for each PE independently until it has been acknowledged by the PE.

1 of N model

This model applies to SPIs only. The interrupt is targeted at a specified set of PEs, and is taken on only one PE in that set. The PE that takes the interrupt is selected in an IMPLEMENTATION DEFINED manner. The architecture applies restrictions on which PEs can be selected, see Enabling the distribution of interrupts .

Note

• The Arm GIC architecture guarantees that a 1 of N interrupt is presented to only one PE listed in the target PE set.

• A 1 of N interrupt might be presented to a PE where the interrupt is not the highest priority interrupt, or where the interrupt is masked by ICC_PMR_EL1 or within the PE. See Interrupt lifecycle .

For SPIs during legacy operation, this model applies when more than one target PE is specified in the target registers.

The hardware implements a mechanism to determine which PE activates the interrupt, if more than one PE can handle the interrupt.

1.2.4 Additional terms

The following additional terms are used throughout this manual:

Idle priority

In GICv3, the idle priority, 0xFF, is the running priority read from ICC_RPR_EL1 on the CPU interface when no interrupts are active on that interface. During legacy operation, the idle priority, as read from GICC_RPR, is IMPLEMENTATION DEFINED, as in GICv2.

Interrupt Identifier (INTID)

The number space that uniquely identifies an interrupt with an associated event and its source. The interrupt is then routed to one or more PEs for handling. PPI and SGI interrupt numbers are local to each PE. SPIs and LPIs have global interrupt numbers for the physical domain. See INTIDs for more information.

Interrupt Routing Infrastructure (IRI)

The Distributor, Redistributors and, optionally, one or more ITSs. See The GIC logical components for more information.

Message-based interrupt

A message-based interrupt is an interrupt that is asserted because of a memory write access to an assigned address. Physical interrupts can be converted to message-based interrupts. Message-based interrupts can support either level-sensitive or edge-triggered behavior, although LPIs are always edge-triggered.

GICv3 supports two mechanisms for message-based interrupts:

• A mechanism for communicating an SPI, where the assigned address is held in the Distributor. In this case the message-based interrupt can be either level-sensitive or edge-triggered.

• A mechanism for communicating an LPI, where the assigned address is held in an ITS, if an ITS is implemented, or in the Redistributor.

Arm recommends the use of LPIs to provide support for MSI and MSI-X capabilities in systems that support PCIe. See Chapter 5 Locality-specific Peripheral Interrupts and the ITS for more information. GICv3 also includes architected support for signaling SPIs using message-based interrupts, see Shared Peripheral Interrupts .

Physical interrupt

An interrupt that targets a physical PE is a physical interrupt. It is signaled to the PE by the physical CPU interface to which the PE is connected.

Running priority

At any given time, the running priority of a CPU interface is either:

• The group priority of the active interrupt, for which there has not been a priority drop on that interface.

• If there is no active interrupt for which there has not been a priority drop on the interface, the running priority is the idle priority 0xFF.

Sufficient priority

The GIC CPU interface compares the priority of an enabled, pending interrupt with all of the following, to determine whether the interrupt has sufficient priority:

• The Priority Mask Register, ICC_PMR_EL1.

• The preemption settings for the interface, as indicated by ICC_BPR0_EL1 and ICC_BPR1_EL1.

• The current running priority, as indicated by ICC_RPR_EL1 for the CPU interface.

• If the interrupt has sufficient priority it is signaled to the connected PE.

Virtual interrupt

An interrupt that targets a VM is a virtual interrupt. It is signaled by the associated virtual CPU interface. See Chapter 6 Virtual Interrupt Handling and Prioritization for more information.

Maintenance interrupt

A physical interrupt that signals key events associated with interrupt handling on a VM to allow the hypervisor to track those events. These events are processed by the hypervisor, and include enabling and disabling a particular group of interrupts. See Maintenance interrupts for more information.

1.3 Supported configurations and compatibility

In Armv8-A, EL2 and EL3 are optional, and a PE can support one, both, or neither of these Exception levels. However:

• A PE requires EL3 to support both Secure and Non-secure state.

• A PE requires EL2 to support virtualization.

• If EL3 is not implemented, there is only a single Security state. This Security state is either Secure state or Non-secure state.

GICv3 supports interrupt handling for all of these configurations, and for execution in both AArch32 state and AArch64 state, in accordance with the interprocessing rules described in Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

1.3.1 Affinity routing configuration

The GICv3 architecture supports affinity routing. It provides optional support for:

• An asymmetric configuration, where affinity routing is enabled for Non-secure state and disabled for Secure state. This provides support for a Secure legacy environment.

• A legacy-only environment where affinity routing is disabled for both Secure state and Non-secure state.

1.3.2 System register configuration

When affinity routing is enabled for execution in both Security states, the GIC must be configured to use System register access to handle physical interrupts. The architecture does not support having affinity routing enabled for a Security state, and not having System register access configured for that Security state. Configuring the GIC this way results in UNPREDICTABLE behavior. When affinity routing is enabled for execution in Non-secure state, the GIC architecture optionally supports legacy operation for virtual interrupts, that is legacy interrupt handling at Non-secure EL1 under the control of a hypervisor executing at EL2.

1.3.3 GIC control and configuration

Many of the GIC registers are available in different forms, to permit effective interrupt handling:

• For two Security states.

• For different interrupt groups.

• Using System register access for GICv3 or memory-mapped access for legacy operation.

When System register access is enabled, control and configuration of the GIC architecture is handled by architected System registers and the associated accesses that define the GIC programmers’ model. See Chapter 12 Programmers’ Model for more information.

Some registers are always memory-mapped, while others use System register access in GICv3, and memory-mapped access for legacy operations.

Table 1-1 shows the registers that are always memory-mapped.

Table 1-1 Memory-mapped registers

• a. There is one copy of each of the Redistributor registers per PE.

• b. There can be more than one ITS in an implementation. Each ITS has its own copy of the GITS registers. Table 1-2 shows the registers that are memory-mapped for legacy operations, but are replaced by System register access in GICv3 when System register access is enabled.

Table 1-2 Memory-mapped registers for legacy operation

Note

• An operating system executing at Non-secure EL1 uses either the GICC_* or the GICV_* registers to control interrupts, and is unaware of the difference.

• The GICR_* and GITS_* registers are introduced in GICv3.

Table 1-3 shows the registers that GICv3 supports when System register access is enabled.

Table 1-3 System registers

The Armv8 support for virtualization and the Exception level at which a PE is operating determine whether the physical CPU interface registers or the virtual CPU interface registers are accessed.

For more information about register names and the factors that affect which register to use, see GIC System register access .

1.3.4 References to the Armv8 architectural state

Table 1-4 shows the Armv8 architectural state that is used with or affects the operation of the GIC.

Table 1-4 Armv8 architectural state affecting GIC operation

• a. Process state, PSTATE, is an abstraction of the process state information. For more information, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

For more information about these registers and fields, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

1.3.5 GICv3 with no legacy operation

In an implementation that does not support legacy operation, affinity routing and System register access are permanently enabled. This means that the associated control bits are RAO/WI. Table 1-5 shows the register fields that are affected by this.

Table 1-5 Control bits for affinity routing and System register access

a. There is a Secure copy and a Non-secure copy of this register.

If Secure Virtualization is supported, this is the only permitted configuration.

1.3.6 GICv3 with legacy operation

Legacy operation is a form of limited backwards compatibility with GICv2 that is provided to allow systems using GICv3 to run code using GICv2, provided that this code meets the restrictions described in this section. Legacy operation is optional in GICv3. See Legacy support of interrupts and asymmetric configurations .

In a GICv3 implementation that supports legacy operation, a maximum of eight PEs, whose individual support for a memory-mapped register interface is IMPLEMENTATION DEFINED, are available as physical or virtual interrupt targets within a given VM. It is IMPLEMENTATION DEFINED:

• Whether legacy operation applies to execution in both Security states, or to execution in Secure state only.

• Whether legacy operation is available only in the virtual CPU interface when executing in Non-secure EL1.

In GICv3, the following restrictions apply to legacy operation:

• The GICv2 feature GICC_CTLR.AckCtl was deprecated in GICv2 and is not supported in GICv3. Correspondingly, even in legacy mode, the behavior is as if the GICC_CTLR.AckCtl bit described in GICv2 is RAZ/WI.

Note

In a GICv3 implementation that supports legacy operation, a VM is permitted to control Non-secure interrupts when GICV_CTLR.AckCtl set to 1. However, Arm deprecates the use of GICV_CTLR.AckCtl.

• The GICv2 configuration lockdown feature and the associated CFGSDISABLE input signal are not supported.

• A hypervisor executing at EL2 can control virtual interrupts only for the PE on which the EL2 software is executing and cannot control virtual interrupts on other PEs.

For legacy operation, an asymmetric configuration is supported where:

• Affinity routing and System register access are enabled in Non-secure state and at EL3.

• Affinity routing and System register access are disabled at Secure EL1.

This allows a secure operating system, running at Secure EL1, to use legacy functionality, provided that it does not configure Non-secure interrupts.

In GICv2 software executing in Secure state could use GICC_AIAR, GICC_AEOIR, GICC_AHPPIR, and GICC_ABPR to control interrupts in Non-secure state. There is no equivalent functionality in asymmetric configurations.