Front Matter

Arm® Generic Interrupt Controller Architecture Specification GIC architecture version 3 and version 4

Copyright © 2008, 2011, 2015-2021 Arm Limited or its affiliates. All rights reserved.

Arm Generic Interrupt Controller Architecture Specification GIC architecture version 3 and version 4

Copyright © 2008, 2011, 2015-2021 Arm Limited or its affiliates. All rights reserved.

Release Information

The following changes have been made to this document.

Change History

Some of the information in this specification was previously published in Arm[®] Generic Interrupt Controller, Architecture version 2.0, Architecture Specification .

Proprietary Notice

This document is protected by copyright and other related rights and the practice or implementation of the information contained in this document may be protected by one or more patents or pending patent applications. No part of this document may be reproduced in any form by any means without the express prior written permission of ARM. No license, express or implied, by estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.

Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use the information for the purposes of determining whether implementations infringe any third party patents.

THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, ARM makes no representation with respect to, and has undertaken no analysis to identify or understand the scope and content of, patents, copyrights, trade secrets, or other rights.

This document may include technical inaccuracies or typographical errors.

TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure of this document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof is not exported, directly or indirectly, in violation of such export laws. Use of the word “partner” in reference to ARM’s customers is not intended to create or refer to any partnership relationship with any other company. ARM may make changes to this document at any time and without notice.

If any of the provisions contained in these terms conflict with any of the provisions of any click through or signed written agreement covering this document with ARM, then the click through or signed written agreement prevails over and supersedes the conflicting provisions of these terms. This document may be translated into other languages for convenience, and you agree that if there is any conflict between the English version of this document and any translation, the terms of the English version of the Agreement shall prevail.

The ARM corporate logo and words marked with ® or ™ are registered trademarks or trademarks of ARM Limited (or its subsidiaries) in the US and/or elsewhere. All rights reserved. Other brands and names mentioned in this document may be the trademarks of their respective owners. Please follow ARM’s trademark usage guidelines at http://www.arm.com/company/policies/trademarks. Copyright © 2008, 2011, 2015-2021 Arm Limited or its affiliates. All rights reserved.

Arm Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.

LES-PRE-20349

Confidentiality Status

This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions in accordance with the terms of the agreement entered into by Arm and the party that Arm delivered this document to.

Product Status

The information in this document is final, that is for a developed product.

Web Address

http://www.arm.com

Progressive terminology commitment

Arm values inclusive communities. Arm recognizes that we and our industry have used terms that can be offensive. Arm strives to lead the industry and create change.

Previous issues of this document included terms that can be offensive. We have replaced these terms.

If you find offensive terms in this document, please contact [email protected].

Contents Arm Generic Interrupt Controller Architecture Specification GIC architecture version 3 and version 4

Glossary

vii viii

Preface

This preface introduces the Arm[®] Generic Interrupt Controller Architecture Specification . It contains the following sections:

• About this specification on page x.

• Using this specification on page xi.

• Conventions on page xiii.

• Additional reading on page xiv.

• Feedback on page xv. Preface About this specification

About this specification

This specification describes the Arm Generic Interrupt Controller (GIC) architecture. It defines versions 3.0, 3.1, 3.2 (GICv3), 4.0, and 4.1 (GICv4) of the GIC architecture.

Throughout this document, references to the GIC or a GIC refer to a device that implements the GIC architecture. Unless the context makes it clear that a reference is to an IMPLEMENTATION DEFINED feature of the device, these references describe the requirements of this specification.

Intended audience

This specification is for users who want to design, implement, or program the GIC in a range of Arm-compliant implementations, from simple uniprocessor implementations to complex multiprocessor systems. It does not assume familiarity with previous versions of the GIC.

The specification assumes that users have some experience of Arm products, and are familiar with the terminology that describes the Armv8 architecture. See the Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile for more information. Preface Using this specification

Using this specification

This specification is organized into the following chapters:

Chapter 1 Introduction

Read this for an overview of the GIC, and information about the terminology that this document uses.

Chapter 2 Distribution and Routing of Interrupts

Read this for information about how the GIC uses affinity routing to distribute interrupts.

Chapter 3 GIC Partitioning

Read this for an overview of the GIC partitioning and information about the GIC logical components. Chapter 4 Physical Interrupt Handling and Prioritization Read this for information about how the GIC handles physical interrupts. Chapter 5 Locality-specific Peripheral Interrupts and the ITS Read this for a description of Locality-specific Peripheral Interrupts (LPIs) and the use of the Interrupt Translation Service (ITS). Chapter 6 Virtual Interrupt Handling and Prioritization Read this for information about how the GIC handles virtual interrupts. Chapter 7 GICv4.0 Virtual LPI Support

Read this for information about how the GIC handles virtual interrupts. Chapter 8 GICv4.1 Virtual Interrupt Support Read this for information about changes to virtual interrupt support in GICv4.1. Chapter 9 Memory Partitioning and Monitoring Read this for a description of Memory Partitioning and Monitoring in the context of the GIC. Chapter 10 Connecting to Armv8-R AArch64 PEs Read this for information about connecting a GIC to PEs that implement Armv8-R64. Chapter 11 Power Management Read this for information about GIC power management. Chapter 12 Programmers’ Model Read this for a description of the GIC register interfaces, and all GIC registers. Chapter 13 System Error Reporting Read this for information about GIC support for error reporting. Chapter 14 Legacy Operation and Asymmetric Configurations Read this for information about GIC support for legacy operation and asymmetric configurations. Appendix A GIC Stream Protocol interface

Read this for a description of the AXI4-Stream protocol standard message-based interface that the GIC Stream Protocol interface uses.

Appendix B Pseudocode Definition

Read this for a definition of the pseudocode that is used in this specification.

Glossary

Read this for definitions of some of the terms used in this specification. Preface Using this specification

Preface Conventions

Conventions

The following sections describe conventions that this book can use:

• Typographic conventions .

• Signals .

• Numbers .

• Pseudocode descriptions .

Typographic conventions

The typographical conventions are:

italic Introduces special terminology, and denotes citations. bold Denotes signal names, and is used for terms in descriptive lists, where appropriate. monospace Used for assembler syntax descriptions, pseudocode, and source code examples. Also used in the main text for instruction mnemonics and for references to other items appearing in assembler syntax descriptions, pseudocode, and source code examples.

SMALL CAPITALS

Used for a few terms that have specific technical meanings, and are included in the Glossary .

Colored text Indicates a link. This can be:

• A URL, for example https://developer.arm.com.

• A cross-reference, that includes the page number of the referenced information if it is not on the current page, for example, About the Generic Interrupt Controller (GIC) on page 1-18.

• A link, to a chapter or appendix, or to a glossary entry, or to the section of the document that defines the colored term, for example, Banked register or GICC_CTLR.

Signals

In general this specification does not define processor signals, but it does include some signal examples and recommendations. The signal conventions are:

Signal level The level of an asserted signal depends on whether the signal is active-HIGH or active-LOW. Asserted means:

• HIGH for active-HIGH signals

• LOW for active-LOW signals.

Lowercase n At the start or end of a signal name denotes an active-LOW signal.

Numbers

Numbers are normally written in decimal. Binary numbers are preceded by 0b, and hexadecimal numbers by 0x. In both cases, the prefix and the associated value are written in a monospace font, for example 0xFFFF0000.

Pseudocode descriptions

This specification uses a form of pseudocode to provide precise descriptions of the specified functionality. This pseudocode is written in a monospace font, and follows the conventions described in the Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile and the Arm[®] Architecture Reference Manual, Armv7-A and Armv7-R edition . Preface Additional reading

Additional reading

This section lists relevant publications from Arm and third parties.

See Arm Developer, https://developer.arm.com for access to Arm documentation.

Arm publications

• AMBA[®] 4 AXI4-Stream Protocol Specification (ARM IHI 0051).

• Arm[®] Architecture Reference Manual, Armv7-A and Armv7-R edition (ARM DDI 0406).

• Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile (ARM DDI 0487).

• Arm[®] Architecture Reference Manual Supplement, Memory System Resource Partitioning and Monitoring (MPAM), for Armv8-A (ARM DDI 0598).

• Arm[®] Generic Interrupt Controller, Architecture version 2.0, Architecture Specification (ARM IHI 0048).

• Arm[®] CoreSight[™] Architecture Specification v3.0 (ARM IHI 0029).

• Arm[®] Server Base System Architecture (SBSA) (ARM-DEN-0029).

• GICv3 and GICv4 Software Overview (DAI 0492).

• • Application Note GIC Stream Protocol Interface (ARM-ECM-0495013).

Other publications

The following books are referred to in this manual, or provide more information:

• JEDEC Solid State Technology Association, Standard Manufacture’s Identification Code , JEP106. Preface Feedback

Feedback

Arm welcomes feedback on its documentation.

Feedback on this manual

• If you have comments on the content of this manual, send an e-mail to [email protected]. Provide: • The title.

• The number, Arm IHI 0069G.

• The page numbers to which your comments apply.

• A concise explanation of your comments.

Arm also welcomes general suggestions for additions and improvements. Preface Feedback

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.

Chapter 2: Distribution and Routing of Interrupts

This chapter describes the distribution and routing of interrupts to a target PE using affinity routing, and the assignment of interrupt IDs. It contains the following sections:

• The Distributor and Redistributors .

• INTIDs .

• Affinity routing .

2.1 The Distributor and Redistributors

The Distributor provides the routing configuration for SPIs, and holds all the associated routing and priority information.

The Redistributor provides the configuration settings for PPIs and SGIs.

A Redistributor always presents the pending interrupt with the highest priority to the CPU interface in finite time. For more information about interrupt prioritization, see Interrupt prioritization .

The highest priority pending interrupt might change because:

• The previous highest priority interrupt has been acknowledged.

• The previous highest priority interrupt has been preempted.

• The previous highest priority interrupt is removed and no longer valid.

• The group interrupt enable has been modified.

• The PE is no longer a participating PE. See Participating nodes .

2.2 INTIDs

Interrupts are identified using ID numbers (INTIDs). The range of INTIDs supported by GICv3 is IMPLEMENTATION DEFINED, according to the following rules:

• For the number of INTID bits supported in the Distributor and Redistributor:

• If LPIs are not supported, the ID space in the Distributor is limited to 10 bits. This is the same as in earlier versions of the GIC architecture.

• If LPIs are supported, the INTID field is IMPLEMENTATION DEFINED in the range of 14-24 bits, as described in the register description for GICD_TYPER.

Note

A Redistributor can be configured through GICR_PROPBASER to use fewer bits than specified by GICD_TYPER.

• For the number of INTID bits supported in the ITS: — If LPIs are supported, the INTID field is IMPLEMENTATION DEFINED in the range of 14-24 bits.

• The size of the INTID field is defined by GITS_TYPER.IDbits.

The ITS must be programmed so that interrupts that are forwarded to a Redistributor are in the range of interrupts that are supported by that Redistributor, otherwise the behavior is UNPREDICTABLE.

• For the number of INTID bits supported in the CPU interface:

  • The GICv3 CPU interface supports either a 16-bit or a 24-bit INTID field, the choice being IMPLEMENTATION DEFINED. The number of physical interrupt identifier bits that are supported is indicated by ICC_CTLR_EL1.IDbits and ICC_CTLR_EL3.IDbits.

The valid INTID space is governed by the implemented size in the CPU interface and the Distributor. It is a programming error to forward an INTID that is greater than the supported size to a CPU interface.

Unused INTID bits are RAZ. This means that any affected bit field is zero-extended.

Table 2-1 shows how the INTID space is partitioned by interrupt type.

Table 2-1 INTIDs

Note The Arm recommended PPI INTID assignments are provided by the Server Base System Architecture, see Arm[®] Server Base System Architecture (SBSA) .

The GICv4 architecture provides a unique INTID space for each VM by supporting a vPEID in addition to the INTID space. See About GIC support for virtualization for more information about VMs and The Interrupt Translation Service for more information about vPEIDs.

Arm strongly recommends that implemented interrupts are grouped to use the lowest INTID numbers and as small a range of INTIDs as possible. This reduces the size of the associated tables in memory that must be implemented, and that discovery routines must check.

Arm strongly recommends that software reserves:

• INTID0 - INTID7 for Non-secure interrupts.

• INTID8 - INTID15 for Secure interrupts.

2.2.1 Special INTIDs

The list of the INTIDs that the GIC architecture reserves for special purposes is as follows:

1020 The GIC returns this value in response to a read of ICC_IAR0_EL1 or ICC_HPPIR0_EL1 at EL3, to indicate that the interrupt being acknowledged is one which is expected to be handled at Secure EL1. This INTID is only returned when the PE is executing at EL3 using AArch64 state, or when the PE is executing in AArch32 state in Monitor mode.

This value can also be returned by reads of ICC_IAR1_EL1 or ICC_HPPIR1_EL1 at EL3 when ICC_CTLR_EL3.RM == 1, see Asymmetric operation and the use of ICC_CTLR_EL3.RM .

1021 The GIC returns this value in response to a read of ICC_IAR0_EL1 or ICC_HPPIR0_EL1 at EL3, to indicate that the interrupt being acknowledged is one which is expected to be handled at Non-secure EL1 or EL2. This INTID is only returned when the PE is executing at EL3 using AArch64 state, or when the PE is executing in AArch32 state in Monitor mode. This value can also be returned by reads of ICC_IAR1_EL1 or ICC_HPPIR1_EL1 at EL3 when ICC_CTLR_EL3.RM == 1, see Asymmetric operation and the use of ICC_CTLR_EL3.RM.

1022 This value applies to legacy operation only. For more information, see Use of the special INTID 1022.

1023 This value is returned in response to an interrupt acknowledge, if there is no pending interrupt with sufficient priority for it to be signaled to the PE, or if the highest priority pending interrupt is not appropriate for the:

• Current Security state.
• Interrupt group that is associated with the System register.

Note These INTIDs do not require an end of interrupt or deactivation.

For more information about the use of special INTIDs, see the descriptions for the following registers:

• ICC_IAR0_EL1.

• ICC_IAR1_EL1.

• ICC_HPPIR0_EL1.

• ICC_HPPIR1_EL1.

2.2.2 Implementations with mixed INTID sizes

Implementations might choose to implement different INTID sizes for different parts of the GIC, subject to the following rules:

• PEs might implement either 16 or 24 bits of INTID.

  Note

  A system might include a mixture of PEs that support 16 bits of INTID and PEs that support 24 bits of INTID.

• The Distributor and Redistributors must all implement the same number of INTID bits.

• In systems that support LPIs, the Distributors and all Redistributors must implement at least 14 bits of INTID. The number of bits that is implemented in the Distributor and Redistributors must not exceed the minimum number that is implemented on any PE in the system.

Note Because interrupts might target any PE, each PE must be able to receive the maximum INTID that can be sent by a Redistributor. This means that the INTID size that is supported by the Redistributors cannot exceed the minimum INTID size that is supported by each PE in the system.

• In systems that do not support LPIs, the Distributor and all Redistributors must implement at least 5 bits of INTID and cannot implement more than 10 bits of INTID. For GIC version 3.1, no more than 13 bits of INTID can be implemented.

• In systems that include one or more ITSs, an ITS might implement any value up to and including the number of bits that are supported by the Distributor and the Redistributors down to a minimum of 14 bits, which is the minimum number that is required for LPI support.

2.2.3 Valid interrupt ID check pseudocode

The following pseudocode describes how the GIC checks whether an INTID for a physical interrupt is valid:

// InterruptIdentifierValid()
// ==========================

boolean InterruptIdentifierValid(bits(64) data, boolean lpiAllowed)

    // First check whether any out of range bits are set
    integer N = CPUInterfaceIDSize();

    if !IsZero(data<63:N>) then
        if GenerateLocalSError() then
            // Reporting of locally generated SEIs is supported
            IMPLEMENTATION_DEFINED "SError INVALID_INTERRUPT_IDENTIFIER";
            UNPREDICTABLE;

    intID = data<INTID_SIZE-1:0>;

    if !lpiAllowed && IsLPI(intID) then        // LPIs are not supported
        if GenerateLocalSError() then
            // Reporting of locally generated SEIs is supported
            IMPLEMENTATION_DEFINED "SError INVALID_INTERRUPT_IDENTIFIER";
        UNPREDICTABLE;

The following pseudocode describes how the GIC checks whether an INTID for a virtual interrupt is valid:

// VirtualIdentifierValid()
// ========================

boolean VirtualIdentifierValid(bits(64) data, boolean lpiAllowed)

    // First check whether any out of range bits are set
    integer N = VIDBits();

    if !IsZero(data<63:N>) then
        if ICH_VTR_EL2.SEIS == '1' then
            // Reporting of locally generated SEIs is supported
            IMPLEMENTATION_DEFINED "SError INVALID_INTERRUPT_IDENTIFIER";
        UNPREDICTABLE;

    intID = data<INTID_SIZE-1:0>;

    if !lpiAllowed && IsLPI(intID) then        // LPIs are not supported
        if ICH_VTR_EL2.SEIS == '1' then
            // Reporting of locally generated SEIs is supported
            IMPLEMENTATION_DEFINED "SError INVALID_INTERRUPT_IDENTIFIER";
        UNPREDICTABLE;

    // Now check for special identifiers
    if IsSpecial(intID) then
        return FALSE;                              // It is a special ID

    // All the checks pass so the identifier is valid
    return TRUE;

The following pseudocode describes CPU interface ID size function.

// CPUInterfaceIDSize()
// Returns TRUE if the value supplied has bits above the implemented range or
// if the value supplied exceeds the maximum configured size in the
// appropriate GITS_BASERn

boolean VCPUOutOfRange(bits(16) vcpu);

2.3 Affinity routing

Affinity routing is a hierarchical address-based scheme to identify specific PE nodes for interrupt routing.

For a PE, the affinity value is defined in MPIDR_EL1 for AArch64 state, and in MPIDR for AArch32 state:

• Affinity routing is a 32-bit value that is composed of four 8-bit affinity fields. These fields are the nodes a , b , c , and d .

• GICv3 using AArch64 state can support:

  • A four level routing hierarchy, a.b.c.d.

  • A three level routing hierarchy, 0.b.c.d.

• GICv3 using AArch32 state only supports three affinity levels.

• ICC_CTLR_EL3.A3V, ICC_CTLR_EL1.A3V, and GICD_TYPER.A3V indicate whether four levels or three levels of affinity are implemented.

Note An implementation that requires four levels of affinity must only support AArch64 state.

The enumeration notation for specifying nodes in an affinity hierarchy is of the following form, where Affx is Affinity level x:

Aff3.Aff2.Aff1.Aff0

Affinity routing for a Security state is enabled in the Distributor, using the Affinity Routing Enable (ARE) bits. Affinity routing is enabled:

• For Secure interrupts, if GICD_CTLR.ARE_S is set to 1.

• For Non-secure interrupts, if the GICD_CTLR.ARE_NS bit is set to 1.

GICD_CTLR.ARE_S and GICD_CTLR.ARE_NS are RAO/WI if affinity routing is permanently enabled.

For the handling of physical interrupts when affinity routing is enabled, System register access must also be enabled, see GIC System register access . For the other cases, see Chapter 14 Legacy Operation and Asymmetric Configurations .

2.3.1 Routing SPIs and SGIs by PE affinity

SPIs are routed using an affinity address and the routing mode information that is held in GICD_IROUTER. SGIs are routed using the affinity address and routing mode information that is written by software when it generates the SGI.

SGIs are generated using the following registers:

• ICC_SGI0R_EL1.

• ICC_SGI1R_EL1.

• ICC_ASGI1R_EL1.

Arm strongly recommends that only values in the range 0-15 are used at affinity level 0 to align with the SGI target list capability. See Software Generated Interrupts .

SPIs and SGIs are routed using different registers:

• SPIs are routed using GICD_IROUTER.Interrupt_Routing_Mode:

  • If GICD_IROUTER.Interrupt_Routing_Mode is cleared to 0, SPIs are routed to a single PE specified by a.b.c.d.

  • If GICD_IROUTER.Interrupt_Routing_Mode is set to 1, SPIs are routed to any PE defined as a participating node:

    • The mechanisms by which the IRI is selects the target PE is IMPLEMENTATION DEFINED.

    • When ICC_CTLR_EL3.PMHE == 1, or ICC_CTLR_EL1.PMHE == 1, the ICC_PMR_EL1 register associated with the PE might be used by the IRI to determine the target PE.

For more information about participating nodes, see Participating nodes .

• SGIs are routed using ICC_SGI0R_EL1.IRM, and ICC_SGI1R_EL1.IRM:

  • If the IRM bit is set to 1, SGIs are routed to all participating PEs in the system, excluding the originating PE.

  • If the IRM bit is cleared to 0, SGIs are routed to a group of PEs, specified by a.b.c.targetlist.

2.3.2 Participating nodes

An enabled SPI configured to use the 1 of N distribution model can target a PE when:

• GICR_WAKER.ProcessorSleep == 0 and the interrupt group of the interrupt is enabled on the PE.

• GICD_CTLR.E1NWF == 1.

• GICR_TYPER.DPGS == 1, and for the interrupt group of the interrupt, GICR_CTLR.{DPG1S, DPG1NS, DPG0} == 0.

For more information about whether a PE can be selected as the target when the 1 of N distribution model is used, see GICR_CTLR, Redistributor Control Register on page 12-621 .

For more information about enabling interrupts and interrupt groups, see Enabling the distribution of interrupts .

2.3.3 Changing affinity routing enables

This manual describes the GICv3 architecture in a system with affinity routing enabled. This means that:

• GICD_CTLR.ARE_NS == 1.

• GICD_CTLR.ARE_S == 1.

If the value of GICD_CTLR.ARE_NS or GICD_CTLR.ARE_S is changed from 1 to 0, the result is UNPREDICTABLE.

When GICD_CTLR. DS == 0, then:

• Changing GICD_CTLR.ARE_S from 0 to 1 is unpredictable except when all of the following apply:

  • GICD_CTLR.EnableGrp0 == 0.

  • GICD_CTLR.EnableGrp1S == 0.

  • GICD_CTLR.EnableGrp1NS == 0.

• Changing GICD_CTLR.ARE_NS from 0 to 1 is unpredictable except when GICD_CTLR. EnableGrp1NS == 0.

When GICD_CTLR.DS == 1, then:

• Changing GICD_CTLR.ARE from 0 to 1 is unpredictable except when all of the following apply: — GICD_CTLR.EnableGrp0 == 0.

  • GICD_CTLR.EnableGrp1 == 0.

Note The effect of clearing GICD_CTLR.EnableGrp0, GICD_CTLR.EnableGrp1S, or GICD_CTLR.EnableGrp1NS, as appropriate, must be visible when changing GICD_CTLR.ARE_S or GICD_CTLR.ARE_NS from 0 to 1. Software can poll GICD_CTLR.RWP to check that writes that clear GICD_CTLR.EnableGrp0, GICD_CTLR.EnableGrp1S, or GICD_CTLR.EnableGrp1NS bits have completed.

Chapter 3: GIC Partitioning

• This chapter describes the GIC logical partitioning. It contains the following sections: • The GIC logical components .

• Interrupt bypass support .

3.1 The GIC logical components

The GICv3 architecture consists of a set of logical components:

• A Distributor .

• A Redistributor for each PE that is supported.

• A CPU interface for each PE that is supported.

• Interrupt Translation Service components (ITS), to support the optional translation of events into LPIs.

The Distributor, Redistributor and ITS are collectively known as an IRI.

Figure 3-1 shows the IRI.

b. There is one Redistributor per PE. c. There is one CPU interface per PE.

Figure 3-1 Interrupt Routing Infrastructure The CPU interface handles physical interrupts at all implemented Exception levels:

• Interrupts that are translated into LPIs are optionally routed via the ITS to the Redistributor and the CPU interface.

• PPIs are routed directly from the source to the local Redistributor.

• SPIs are routed from the source through the Distributor to the target Redistributor and the associated CPU interface.

• SGIs are generated by software through the CPU interface and Redistributor. They are then routed through the Distributor to one or more target Redistributors and the associated CPU interfaces.

In GICv3, the ITS is an optional component and translates events into physical LPIs. The architecture also supports direct LPIs that do not require the use of an ITS. Where LPIs are supported, it is IMPLEMENTATION DEFINED whether either:

• Direct LPIs are supported by accessing the registers in the Redistributors.

• LPI support is provided by the ITS.

An implementation must only support one of these methods.

In GICv4, the inclusion of at least one ITS is mandatory to provide support for the direct injection of virtual LPIs. Figure 3-2 shows the GIC partitioning in an implementation that includes an ITS.

Figure 3-2 GIC logical partitioning with an ITS

The mechanism for communication between the ITS and the Redistributors is IMPLEMENTATION DEFINED.

The mechanism for communication between the CPU interfaces and the Redistributors is also IMPLEMENTATION DEFINED.

Note Arm recommends that an implementation uses the GIC Stream Protocol for communication between the CPU interfaces and the Redistributors, see Appendix A GIC Stream Protocol interface .

Figure 3-3 shows the GIC partitioning in an implementation that does not include an ITS and that supports direct LPIs. 3.1 The GIC logical components

The following list describes the components that are depicted in Figure 3-2 in more detail:

Distributor

The Distributor performs interrupt prioritization and distribution of SPIs and SGIs to the Redistributors and CPU interfaces that are connected to the PEs in the system. GICD_CTLR provides global settings for:

• Enabling affinity routing.

• Disabling security.

• Enabling Secure and Non-secure Group 1 interrupts.

• Enabling Group 0 interrupts.

For SPIs, the Distributor provides a programming interface for:

• Enabling or disabling SPIs.

• Setting the priority level of each SPI.

• Routing information for each SPI.

• Setting each SPI to be level-sensitive or edge-triggered.

• Generating message-based SPIs.

• Assigning each SPI to an interrupt group.

• Controlling the pending and active state of SPIs.

The Distributor registers are identified by the GICD_ prefix.

See Chapter 2 Distribution and Routing of Interrupts for more information.

Note When handling physical interrupts during legacy operation, the Distributor controls the configuration information for PPIs and SGIs. See Chapter 14 Legacy Operation and Asymmetric Configurations .

Interrupt translation service, ITS

The ITS is an OPTIONAL hardware mechanism in the GICv3 architecture that routes LPIs to the appropriate Redistributor. Software uses a command queue to configure an ITS. Table structures in memory that are associated with an ITS translate an EventID associated with a device into a pending INTID for a PE.

The ITS is not optional in GICv4, and all GICv4 implementations must include at least one ITS.

See The Interrupt Translation Service for more information.

Redistributor A Redistributor is the part of the IRI that is connected to the CPU interface of the PE. The Redistributor holds the control, prioritization, and pending information for all physical LPIs using data structures that are held in memory. Two registers in the Redistributor point to these data structures:

• GICR_PROPBASER.

• GICR_PENDBASER.

In GICv4, the Redistributor also includes registers to handle virtual LPIs that are forwarded by an ITS to a Redistributor and directly to a VM, without involving the hypervisor. This is referred to as a direct injection of virtual interrupts into a VM.

In GICv4, the Redistributors collectively host the control, prioritization, and pending information for all virtual LPIs using data structures that are held in memory. Two registers in the Redistributor point to these data structures:

• GICR_VPROPBASER.

• GICR_VPENDBASER.

In an implementation that supports LPIs but does not include an ITS, the GICR_* registers contain a simple memory-mapped interface to signal and control physical LPIs.

Redistributors provide a programming interface for:

• Identifying, controlling, and configuring supported features to enable interrupts and interrupt routing of the implementation.

• Enabling or disabling SGIs and PPIs.

• Setting the priority level of SGIs and PPIs.

• Setting each PPI to be level-sensitive or edge-triggered.

• Assigning each SGI and PPI to an interrupt group.

• Controlling the pending state of SGIs and PPIs.

• Controlling the active state of SGIs and PPIs.

• Power management support for the connected PE.

• Where LPIs are supported, base address control for the data structures in memory that support the associated interrupt properties and their pending status.

• Where GICv4 is supported, base address control for the data structures in memory that support the associated virtual interrupt properties and their pending status.

The Redistributor registers are identified by the GICR_ prefix.

See Affinity routing and The Distributor and Redistributors for more information about the Redistributor.

CPU interface

The GIC architecture supports a CPU interface that provides a register interface to a PE in the system. Each CPU interface provides a programming interface for:

• General control and configuration to enable interrupt handling in accordance with the Security state and legacy support requirements of the implementation.

• Acknowledging an interrupt.

• Performing a priority drop.

• Deactivation of an interrupt.

• Setting an interrupt priority mask for the PE.

• Defining the preemption policy for the PE.

• Determining the highest priority pending interrupt for the PE.

The CPU interface has several components:

• A component that allows a supervisory level of software to control the handling of physical interrupts. The registers that are associated with this are identified by the ICC_ prefix.

• A component that allows a supervisory level of software to control the handling of virtual interrupts. The registers that are associated with this are identified by the ICV_ prefix.

• A component that allows a hypervisor to control the set of pending interrupts. The registers that are associated with this are identified by the ICH_ prefix.

Note The System registers in the CPU interface are associated with software that is handling interrupts in the physical domain, or with execution at Non-secure EL1 as part of a VM. The configuration of HCR_EL2 determines whether the accesses are to the physical resources or the virtual resources.

The System registers accessible at EL2 that are used for controlling the list of active, pending, and active and pending, virtual interrupts for a PE are identified by the ICH_ prefix.

For more information on handling physical interrupts, see Chapter 4 Physical Interrupt Handling and Prioritization .

For more information on handling virtual interrupts, see Chapter 6 Virtual Interrupt Handling and Prioritization .

3.2 Interrupt bypass support

A CPU interface optionally includes interrupt signal bypass, so that, when the signaling of an interrupt by the interface is disabled, a legacy interrupt signal is passed to the interrupt request input on the PE, bypassing the GIC functionality.

It is IMPLEMENTATION DEFINED whether bypass is supported.

The controls to determine whether GICv3 FIQ and IRQ outputs or the bypass signals are used differ depending on whether System register access is enabled.

When System register access is enabled, bypass disable is controlled at the highest implemented Exception level using two bits in ICC_SRE_EL1, ICC_SRE_EL2, or ICC_SRE_EL3, as appropriate:

• For FIQ bypass, this is the DFB bit.

• For IRQ bypass, this is the DIB bit.

This bypass mechanism is used when System register access is enabled. For information about bypass support during legacy operation, see Legacy operation and bypass support .

The interrupt groups that are supported by the GIC are allocated to FIQs and IRQs, as described in Interrupt grouping . Interrupt groups must be disabled at the CPU interface when bypass is enabled, otherwise the behavior of the GICv3 implementation is UNPREDICTABLE. This means that:

• ICC_IGRPEN0_EL1.Enable must have the value 0 when ICC_SRE_ELx.DFB == 0.

• ICC_IGRPEN1_EL1.Enable must have the value 0 when ICC_SRE_ELx.DIB == 0.

For more information about enabling interrupts, see Enabling the distribution of interrupts .

For information about the behavior when System register access is not enabled, see Chapter 14 Legacy Operation and Asymmetric Configurations .

For FIQs, the following pseudocode determines the source for interrupt signaling to a PE.

if ICC_SRE_EL3.SRE == 1 then
    if ICC_SRE_EL3.DFB == 0 then
        if ICC_SRE_EL1.SRE Secure == 1 then
            BypassFIQsource
        else
            use legacy bypass support
    else
        use GICv3 FIQ output
else
    use legacy bypass support

For IRQs, the following pseudocode determines the source for interrupt signaling to a PE.

if ICC_SRE_EL3.SRE == 1 then
    if ICC_SRE_EL3.DIB == 0 then
        if ICC_SRE_EL1.SRE Secure == 1 then
            BypassIRQsource
        else
            use legacy bypass support
    else
        use GICv3 IRQ output
else
    use legacy bypass support

Chapter 4: Physical Interrupt Handling and Prioritization

This chapter describes the fundamental aspects of GIC interrupt handling and prioritization. It contains the following sections:

• Interrupt lifecycle.

• Locality-specific Peripheral Interrupts.

• Private Peripheral Interrupts.

• Software Generated Interrupts.

• Shared Peripheral Interrupts.

• Interrupt grouping.

• Enabling the distribution of interrupts.

• Interrupt prioritization.

4.1 Interrupt lifecycle

GIC interrupt handling is based on the GIC interrupt lifecycle, a series of high-level processes that apply to any interrupt using the GIC architecture. The interrupt lifecycle provides a basis for describing the detailed steps of the interrupt handling process. The GIC also maintains a state machine that controls interrupt state transitions during the lifecycle.

Figure 4-1 shows the GIC interrupt lifecycle for physical interrupts.

1. Generate interrupt. An interrupt is generated either by the peripheral or by software.

2. Distribute. The IRI performs interrupt grouping, interrupt prioritization, and controls the forwarding of interrupts to the CPU interfaces.

3. Deliver. A physical CPU interface delivers interrupts to the corresponding PE.

4. Activate. When software running on a PE acknowledges an interrupt, the GIC sets the highest active priority to that of the activated interrupt, and for SPIs, SGIs, and PPIs the interrupt becomes active.

5. Priority drop. Software running on the PE signals to the GIC that the highest priority interrupt has been handled to the point where the running priority can be dropped. The running priority then has the value that it had before the interrupt was acknowledged. This is the point where the end of interrupt is indicated by the interrupt handler. The end of the interrupt can be configured to also perform deactivation of the interrupt.

6. Deactivation. Deactivation clears the active state of the interrupt, and thereby allows the interrupt, when it is pending, to be taken again. Deactivation is not required for LPIs. Deactivation can be configured to occur at the same time as the priority drop, or it can be configured to occur later as the result of an explicit interrupt deactivation operation. This latter approach allows for software architectures where there is an advantage to separating interrupt handling into initial handling and scheduled handling.

4.1.1 Physical CPU interface

A CPU interface provides an interface to a PE that is connected to the GIC. Each CPU interface is connected to a single PE. A CPU interface receives pending interrupts prioritized by the IRI, and determines whether the interrupt is a member of a group that is enabled in the CPU interface and has sufficient priority to be signaled to the PE. At any time, the connected PE can determine the:

• INTID of its highest priority pending interrupt, by reading ICC_HPPIR0_EL1 or ICC_HPPIR1_EL1.

• The running priority of the CPU interface by reading ICC_RPR_EL1.

Note

The priority of the highest priority active interrupt for which there has not been a priority drop is also known as the running priority.

When an LPI is acknowledged, the pending state for the interrupt changes to not pending in the Redistributor. The Redistributor does not maintain an active state for LPIs.

When the PE acknowledges an SGI, a PPI, or an SPI at the CPU interface, the IRI changes the status of the interrupt to active if:

• It is an edge-triggered interrupt, and another edge has not been detected since the interrupt was acknowledged.

• It is a level-sensitive interrupt, and the level has been deasserted since the interrupt was acknowledged.

When the PE acknowledges an SGI, a PPI, or an SPI at the CPU interface, the IRI changes the status of the interrupt to active and pending if:

• It is an edge-triggered interrupt, and another edge has been detected since the interrupt was acknowledged.

• It is a level-sensitive interrupt, and the level has not been deasserted since the interrupt was acknowledged.

When the PE acknowledges an SGI, a PPI, or an SPI at the CPU interface, the CPU interface can signal another interrupt to the PE, to preempt interrupts that are active on the PE. If there is no pending interrupt with sufficient priority to be signaled to the PE, the interface deasserts the interrupt request signal to the PE.

The following stages of the interrupt lifecycle are described in the remainder of this section:

• Activation .

• Priority drop.

• Deactivation.

The priority drop and deactivation can be performed as a single operation or can be split, as defined by ICC_CTLR_EL1.EOImode and ICC_CTLR_EL3.EOImode_EL3.

Activation

The interrupt handler reads ICC_IAR0_EL1 for Group 0 interrupts, and ICC_IAR1_EL1 for Group 1 interrupts, in the corresponding CPU interface to acknowledge the interrupt. This read returns either:

• The INTID of the highest priority pending interrupt, if that interrupt is of sufficient priority for it to be signaled to the PE. This is the normal response to an interrupt acknowledge.

• Under certain conditions, an INTID that indicates a special interrupt number, see INTIDs.

Whether a read of ICC_IAR0_EL1 and ICC_IAR1_EL1 returns a valid INTID depends on:

• Which of the two registers is accessed.

• The Security state of the PE.

• Whether there is a pending interrupt of sufficient priority to be signaled to the PE, and if so, whether:

  • The highest priority pending interrupt is a Secure Group 1 or a Non-secure Group 1 interrupt.

  • Interrupt signaling is enabled for that interrupt group.

• The Exception level at which the PE is executing.

All interrupts, when acknowledged, modify the Active Priorities Registers . See System register access to the Active Priorities registers. 4.1 Interrupt lifecycle

In certain circumstances, the value of SCR_EL3.NS affects the value returned when a PE acknowledges an interrupt. That is, when the PE is executing at EL3, a Secure read of ICC_IAR0_EL1 returns a special interrupt number that indicates the required Security state transition for the highest priority pending interrupt. Otherwise, the INTID is returned.

For SGIs in a multiprocessor implementation, the GIC uses the targeted list model, where the acknowledgement of an interrupt by one PE has no effect on the state of the interrupt on other CPU interfaces. When a PE acknowledges the interrupt, the pending state of the interrupt is cleared only for that PE. The interrupt remains pending for the other PEs.

The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a returned INTID are not guaranteed to be visible until after the execution of a DSB.

Priority drop

After an interrupt has been acknowledged, a valid write to ICC_EOIR0_EL1 for Group 0 interrupts, or a valid write to ICC_EOIR1_EL1 for Group 1 interrupts, results in a priority drop.

A valid write to ICC_EOIR0_EL1 or ICC_EOIR1_EL1 to perform a priority drop is required for each acknowledged interrupt, even for LPIs which do not have an active state. A priority drop must be performed by the same PE that activated the interrupt.

Note A valid write is a write that is:

• Not UNPREDICTABLE.

• Not ignored.

• Not writing an INTID that is either unsupported or within the range 1020-1023.

For each CPU interface, the GIC architecture requires the order of the valid writes to ICC_EOIR0_EL1 and ICC_EOIR1_EL1 to be the exact reverse of the order of the reads from ICC_IAR0_EL1 and ICC_IAR1_EL1, as shown in Figure 4-2.

• The priority of the highest-priority active interrupt for which there has been no write to ICC_EOIR0_EL1 or ICC_EOIR1_EL1.

• The idle priority, 0xFF, if there is no active interrupt.

Note For compatibility with possible extensions to the GIC architecture specification, software must preserve the entire register value read from ICC_IAR0_EL1 and ICC_IAR1_EL1 when it acknowledges the interrupt, and use that entire value for the corresponding write to ICC_EOIR0_EL1 and ICC_EOIR1_EL1 by the same PE.

When GICD_CTLR.DS == 0:

• A write to ICC_EOIR0_EL1 performs a priority drop for Group 0 interrupts.

• A write to ICC_EOIR1_EL1 performs a priority drop for Non-secure Group 1 interrupts, if the PE is operating in Non-secure state or at EL3.

• When operating in Secure state, a write to ICC_EOIR1_EL1 performs a priority drop for Secure Group 1 interrupts.

When GICD_CTLR.DS == 1:

• A write to ICC_EOIR0_EL1 performs a priority drop for Group 0 interrupts.

• A write to ICC_EOIR1_EL1 performs a priority drop for Group 1 interrupts.

Deactivation

PPIs, SGIs, and SPIs have an active state in the IRI and must be deactivated.

SGIs and PPIs must be deactivated by the PE that activated the interrupt. SPIs can be deactivated by a different PE.

Interrupt deactivation is required to change the state of an interrupt either:

• From active and pending to pending.

• From active to inactive.

Depending on the Exception level and Security state, ICC_CTLR_EL1.EOImode and

ICC_CTLR_EL3.EOImode_EL3 in the appropriate CPU Interface Control Register determine whether priority drop and interrupt deactivation happen together or separately:

• The priority drop and interrupt deactivation happen together when ICC_CTLR_EL1.EOImode or ICC_CTLR_EL3.EOImode_EL3 in the CPU interface is 0, and the PE writes to ICC_EOIR0_EL1 or ICC_EOIR1_EL1. In this case a write to ICC_DIR_EL1 is not required.

• The priority drop and interrupt deactivation are separated when ICC_CTLR_EL1.EOImode or ICC_CTLR_EL3.EOImode_EL3 in the CPU interface is 1, and the PE writes to ICC_EOIR0_EL1 or ICC_EOIR1_EL1. In this case:

  • The priority drop happens when the PE writes to ICC_EOIR0_EL1 or ICC_EOIR1_EL1.

  • Interrupt deactivation happens later, when the PE writes to ICC_DIR_EL1. A valid write to ICC_DIR_EL1 results in interrupt deactivation for a Group 0 or a Group 1 interrupt.

There are no ordering requirements for writes to ICC_DIR_EL1. If software writes to ICC_DIR_EL1 when the following conditions are true, the results are unpredictable:

• The appropriate EOIMode bit is cleared to 0.

• The ICC_CTLR_EL1.EOImode or ICC_CTLR_EL3.EOIMode_EL3 is set to 1 and there has not been a corresponding write to ICC_EOIR0_EL1 or ICC_EOIR1_EL1.

When ICC_CTLR_EL1.EOImode or ICC_CTLR_EL3.EOIMode_EL3 == 1 but the interrupt is not active in the Distributor, writes to ICC_DIR_EL1 must be ignored. If supported, an implementation might generate a system error. Table 4-1 shows how a write to ICC_EOIR0_EL1 or ICC_EOIR1_EL1 affects deactivation.

Table 4-1 Effect of writing to ICC_EOIR0_EL1 or ICC_EOIR1_EL1

When GICD_CTLR.DS == 0, access to certain registers is restricted. See Interrupt grouping and security.

The following pseudocode determines whether EOImode is set for the current Exception level and Security state:

// EOImodeSet()
// ============

boolean EOImodeSet()

     if HaveEL(EL3) then
         // EL3 is implemented so return the value appropriate to the EL and security state
         if IsEL3OrMon() && ICC_SRE_EL3.SRE == '1'1 then
             // In EL3
             EOImode = ICC_CTLR_EL3.EOImode_EL3;

         elsif IsSecure() then
             EOImode = ICC_CTLR_EL3.EOImode_EL1S;

         else                                                  // Non-secure
              EOImode = ICC_CTLR_EL3.EOImode_EL1NS;
     else
         // No EL3 so return the value from ICC_CTLR_EL1
         EOImode = ICC_CTLR_EL1.EOImode;

     return EOImode == '1';

Effect of Security states on writes to ICC_DIR_EL1

The effect of a write to ICC_DIR_EL1 depends on whether the GIC supports one or two Security states:

• If GICD_CTLR.DS == 0, a valid:

  - Secure write to ICC_DIR_EL1 deactivates the specified interrupt, regardless of whether that interrupt is a Group 0 or a Group 1 interrupt.
  

  • Non-secure write to ICC_DIR_EL1 deactivates the specified interrupt only if that interrupt is a Non-secure Group 1 interrupt.

• If GICD_CTLR.DS == 1, a valid write to ICC_DIR_EL1 deactivates the specified interrupt, regardless of whether that interrupt is a Group 0 or Group 1 interrupt. Table 4-2 shows the behavior of valid writes to ICC_DIR_EL1. In an implementation that supports only a single Security state, valid writes have the behavior shown for Secure writes to ICC_DIR_EL1.

Table 4-2 Behavior of writes to ICC_DIR_EL1

Secure EL2 can only be entered when SCR_EL3.EEL2 == 1.

4.1.2 Interrupt handling state machine

The GIC maintains a state machine for each supported interrupt. The possible states of an interrupt are:

• Inactive.

• Pending.

• Active.

• Active and pending.

PPIs, SGIs, and SPIs can have an active and pending state. Interrupts that are active and pending are never signaled to a connected PE. LPIs have a pending state that is held in memory associated with a Redistributor, and therefore a PE. This also applies to directly injected virtual LPIs, see About GICv4.0 virtual Locality-specific Peripheral Interrupt support.

Note There is no active or active and pending state for LPIs.

Figure 4-3 shows an instance of the interrupt handling state machine, and the possible state transitions.

a. Not applicable for SGIs when GICD_CTLR.nASSGIreq==1,
and for LPIs. Figure 4-3 Interrupt handling state machine

Note LPIs do not have an active state in the Redistributor, but do require an active priority in the CPU interface. See Chapter 5 Locality-specific Peripheral Interrupts and the ITS for more information.

Arm expects hardware implementations to report GICD_TYPER2.nASSGIcap==0, indicating that GICD_CTLR.nASSGIreq is RES0.

When interrupt forwarding by the Distributor and interrupt signaling by the CPU interface are enabled, the conditions that cause each of the state transitions are as follows:

Transition A1 or A2, add pending state

This transition occurs when the interrupt becomes pending, either as a result of the peripheral generating the interrupt or as result of software generating the interrupt.

Transition B1 or B2, remove pending state

This transition occurs when the interrupt has been deasserted by the peripheral, if the interrupt is a level-sensitive interrupt, or when software has changed the pending state.

For LPIs, it also occurs on acknowledgement of the interrupt.

Transition C, pending to active

This transition occurs on acknowledgement of the interrupt by the PE for edge-triggered SPIs, SGIs, and PPIs.

For SPIs, SGIs, and PPIs, this transition occurs when software reads an INTID value from ICC_IAR0_EL1 or ICC_IAR1_EL1.

Transition D, pending to active and pending

This transition occurs on acknowledgement of the interrupt by the PE for level-sensitive SPIs, SGIs, and PPIs.

Transition E1 or E2, remove active state

This transition occurs when software deactivates an interrupt for SPIs, SGIs, and PPIs.

4.2 Locality-specific Peripheral Interrupts

LPIs are targeted peripheral interrupts that are routed to a specific PE within the affinity hierarchy. In a system where two Security states are enabled, LPIs are always Non-secure Group 1 interrupts. LPIs only support edge-triggered behavior. For more information about LPIs, see LPIs.

4.3 Private Peripheral Interrupts

PPIs are interrupts that target a single, specific PE, and different PEs can use the same INTID to indicate different events. PPIs can be Group 0 interrupts, Secure Group 1 interrupts, or Non-secure Group 1 interrupts. They can support either edge-triggered or level-sensitive behavior.

An optional extended PPI range uses INTIDs 1056 - 1119. This range of PPIs is not available when the GIC is operating in legacy mode. GICR_TYPER.PPInum indicates whether the extended PPI range is supported or not.

Note Commonly, Arm expects that PPIs are used by different instances of the same interrupt source on each PE, thereby allowing a common INTID to be used for PE specific events, such as the interrupts from a private timer.

4.4 Software Generated Interrupts

SGIs are typically used for inter-processor communication, and are generated by a write to an SGI register in the GIC. SGIs can be either Group 0 or Group 1 interrupts, and they can support only edge-triggered behavior.

The registers associated with the generation of SGIs are part of the CPU interface:

• A PE generates a Group 1 SGI by writing to ICC_SGI1R_EL1 or ICC_ASGI1R_EL1.

• A PE generates a Group 0 SGI by writing to ICC_SGI0R_EL1.

• Routing information is supplied as the bitfield value in the write to the register that generated the SGI. The SGI can be routed to:

  • The group of PEs specified by a.b.c.targetlist. This can include the originating PE.

  • All participating PEs in the system, excluding the originating PE.

See Routing SPIs and SGIs by PE affinity for more information.

ICC_SGI1R_EL1 allows software executing in a Secure state to generate Secure Group 1 SGIs.

ICC_SGI1R_EL1 allows software executing in a Non-secure state to generate Non-secure Group 1 SGIs.

ICC_ASGI1R_EL1 allows software executing in a Secure state to generate Non-secure Group 1 SGIs.

ICC_ASGI1R_EL1 allows software executing in a Non-secure state to generate Secure Group 1 SGIs, if permitted by the settings of GICR_NSACR in the Redistributor corresponding to the target PE.

ICC_SGI0R_EL1 allows software executing in Secure state to generate Group 0 SGIs.

ICC_SGI0R_EL1 allows software executing in Non-secure state to generate Group 0 SGIs, if permitted by the settings of GICR_NSACR in the Redistributor corresponding to the target PE.

For more information about the use of control registers to forward SGIs to a target PE, see Table 12-14.

4.5 Shared Peripheral Interrupts

SPIs are peripheral interrupts 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 either Group 0 or Group 1 interrupts, and they can support either edge-triggered or level-sensitive behavior.

An optional extended SPI range uses INTIDs 4096 - 5119. This range of SPIs is not available when the GIC is operating in legacy mode. GICD_TYPER.ESPI indicates whether the extended SPI range is supported or not.

SPIs can be either wired-based or message-based interrupts.

Support for message-based SPIs is optional, and can be discovered through GICD_TYPER.MBIS. Message-based SPIs can be:

• Generated by a write to GICD_SETSPI_NSR or GICD_SETSPI_SR

• Cleared by a write to GICD_CLRSPI_NSR or GICD_CLRSPI_SR.

The effect of a write to these registers depends on whether the targeted SPI is configured to be an edge-triggered or a level-sensitive interrupt:

• For an edge-triggered interrupt, a write to GICD_SETSPI_NSR or GICD_SETSPI_SR sets the interrupt pending. The interrupt is no longer pending when it is activated, or when it is cleared by a write to GICD_CLRSPI_NSR, GICD_CLRSPI_SR, or GICD_ICPENDR.

• For a level-sensitive interrupt, a write to GICD_SETSPI_NSR or GICD_SETSPI_SR sets the interrupt pending. It remains pending until it is deasserted by a write to GICD_CLRSPI_NSR or GICD_CLRSPI_SR. If the interrupt is activated between the time it is asserted by a write to GICD_SETSPI_NSR or GICD_SETSPI_SR and the time it is deactivated by a write to GICD_CLRSPI_NSR or GICD_CLRSPI_SR, then the interrupt becomes active and pending.

  • It is IMPLEMENTATION DEFINED for a level-sensitive interrupt whether a write to GICD_ICPENDR has any effect on an interrupt that has been set pending by a write to GICD_SETSPI_NSR or GICD_SETSPI_SR, or whether a write to GICD_CLRSPI_NSR or GICD_CLRSPI_SR has any effect on an interrupt that has been set pending by a write GICD_ISPENDR.

  • It is IMPLEMENTATION DEFINED whether acknowledging an interrupt that was set pending by a write to GICD_ISPENDR clears the pending state.

• Changing the configuration of an interrupt from level-sensitive to edge-triggered, or from edge-triggered to level-sensitive, when there is a pending interrupt, leaves the interrupt in an UNKNOWN state.

Figure 4-4 shows how message-based interrupt requests can trigger SPIs.

Figure 4-4 Triggering SPIs

4.6 Interrupt grouping

GICv3 uses interrupt grouping as a mechanism to align interrupt handling with the Armv8 Exception model and Security model.

In a system with two Security states, an interrupt is configured as one of the following:

• A Group 0 physical interrupt:

  • Arm expects these interrupts to be handled at EL3.

• A Secure Group 1 physical interrupt:

  • Arm expects these interrupts to be handled at Secure EL1 or Secure EL2 in a system using Secure virtualization.

• A Non-secure Group 1 physical interrupt:

  • Arm expects these interrupts to be handled at Non-secure EL2 in systems using virtualization, or at Non-secure EL1 in systems not using virtualization.

In a system with one Security state an interrupt is configured to be either:

• Group 0.

• Group 1.

At the System level, GICD_CTLR.DS indicates if the GIC is configured with one or two Security states. For more information about Security, see Interrupt grouping and security.

These interrupt groups are mapped onto the Armv8 FIQ and IRQ exceptions, see Interrupt assignment to IRQ and FIQ signals.

GICD_IGROUPR and GICD_IGRPMODR configure the interrupt group for SPIs, and GICD_IGROUPRE and GICD_IGRPMODRE configure the interrupt group for the extended SPI range. n is greater than zero.

GICR_IGROUPR0 and GICR_IGRPMODR0 configure the interrupt group for SGIs and PPIs, and GICR_IGROUPRE and GICR_IGRPMODRE configure the interrupt group for the extended PPI range. n is greater than zero.

Note

When GICD_CTLR.DS == 0, LPIs are always Non-secure Group 1 interrupts. When GICD_CTLR.DS == 1, LPIs are always Group 1 interrupts.

System registers control and configure Group 0 and Group 1 interrupts:

• For Group 0 interrupts, software uses: — ICC_IAR0_EL1 to read a Group 0 INTID on an interrupt acknowledge.

  • ICC_EOIR0_EL1 to write a Group 0 interrupt completion.

  • ICC_BPR0_EL1 to configure the binary point for Group 0 prioritization. This register is also used for Group 1 prioritization when ICC_CTLR_EL1.CBPR == 1.

  • ICC_HPPIR0_EL1 to read the highest Group 0 interrupt that is currently pending.

  • ICC_IGRPEN0_EL1 to enable Group 0 interrupts at the CPU interface.

• For Group 1 interrupts, software uses:

  • ICC_IAR1_EL1 to read a Group 1 INTID on an interrupt acknowledge.

  • ICC_EOIR1_EL1 to write a Group 1 interrupt completion.

  • ICC_BPR1_EL1 to configure the binary point for Group 1 prioritization for the current Security state.

  • ICC_HPPIR1_EL1 to read the highest Group 1 interrupt that is currently pending.

  • ICC_IGRPEN1_EL1 to enable Group 1 interrupts for the target Security state of the interrupt.

In a system with two Security states, Group 0 interrupts are always Secure. For more information about grouping and Security, see Interrupt grouping and security.

4.6.1 Interrupt grouping and security

The Arm architecture provides two Security states, each with an associated physical memory address space:

• Secure state.

• Non-secure state.

A software hierarchy of user and privileged code can execute in either state, and software executing in Non-secure state can only access Secure state through a system call to the Secure monitor. The GIC architecture supports the routing and handling of interrupts associated with both Security states.

GICD_CTLR.DS indicates whether a GIC is configured to support the Armv8-A Security model. This configuration affects:

• Register access, see GIC System register access.

• The interrupt groups that are supported.

When GICD_CTLR.DS == 0:

• The GIC supports two Security states, Secure state and Non-secure state.

• The GIC supports three interrupt groups:

  - Group 0.
  
  - Secure Group 1.
  

  • Non-secure Group 1.

• Both the Security state and GICR_NSACR determine whether an SGI can be generated.

• The Security state is checked during:

  - Configuration of an interrupt.
  
  - Acknowledgement of an interrupt.
  

  • Priority drop.

  • Deactivation.

• Secure Group 1 interrupts are treated as Group 0 by a CPU interface if:

  • The PE does not implement EL3.

  • ICC_SRE_EL1(S).SRE == 0.

When GICD_CTLR.DS == 1:

• The GIC supports only a single Security state. This can be either Secure state or Non-secure state.

• The GIC supports two interrupt groups:

  • Group 0.

  • Group 1.

• SGIs can be generated regardless of the settings in GICR_NSACR.

• The Security state is not checked during:

  • Configuration of an interrupt.

  • Acknowledgement of an interrupt.

  • Priority drop.

• Deactivation.

In a multiprocessor system, one or more PEs within the system might support accesses to resources that are available only in Secure state, or accesses to resources that are available only in Non-secure state. It is a programming error if software configures:

• A Group 0 or Secure Group1 interrupt to be forwarded to a PE that only supports Non-secure state.

• A Non-secure Group1 interrupt to be forwarded to a PE that only supports Secure state.

There is a dedicated register for the priority grouping for each interrupt group, ICC_BPR0_EL1 for Group 0 interrupts and ICC_BPR1_EL1 for Group 1 interrupts. However, it is possible to configure a common Binary Point Register for both groups using:

• ICC_CTLR_EL1.CBPR.

• ICC_CTLR_EL3.CBPR_EL1NS and ICC_CTLR_EL3.CBPR_EL1S for an independent common Binary Point Register configuration of Non-secure Group 1 and Secure Group 1 interrupts. For information about interrupt grouping and legacy operation, see Chapter 14 Legacy Operation and Asymmetric Configurations .

4.6.2 Interrupt assignment to IRQ and FIQ signals

This subsection applies to implementations in which affinity routing is enabled.

A Group 0 physical interrupt, when it is the highest priority pending interrupt and has sufficient priority, is always signaled as an FIQ.

A Group 1 physical interrupt, when it is the highest priority pending interrupt and has sufficient priority, is signaled as an FIQ if either of the following conditions is true, otherwise it is signaled as an IRQ:

• It is an interrupt for the other Security state, that is, the Security state in which the PE is not executing.

• • The PE is executing at EL3.

Table 4-3 summarizes the signaling of interrupts when EL3 is using AArch64 state.

Table 4-3 Interrupt signals for two Security states when EL3 is using AArch64 state

Table 4-4 summarizes the signaling of interrupts when EL3 is using AArch32 state. Secure EL2 is not present when EL3 is using AArch32 state.

Table 4-4 Interrupt signals for two Security states when EL3 is using AArch32 state

Table 4-5 summarizes the signaling of interrupts in systems that support only a single Security state, that is where EL3 is not implemented or when GICD_CTLR.DS == 1.

Table 4-5 Interrupt signals for a single Security state

The assertion and de-assertion of IRQs and FIQs are affected by the current Exception level and Security state of the PE. As part of the Context Synchronization that occurs as the result of taking or returning from an exception, the CPU interface ensures that IRQ and FIQ are both appropriately asserted or deasserted for the Exception level and Security state that the PE is entering.

Note For the effects of GICC_CTLR.FIQEn on interrupt signaling in asymmetric configurations, see The asymmetric configuration.

4.6.3 Interrupt routing and System register access

When executing in AArch64 state, interrupt routing to an Exception level is controlled by the following bits:

• SCR_EL3.FIQ, SCR_EL3.NS, and HCR_EL2.FMO control FIQs.

• SCR_EL3.IRQ, SCR_EL3.NS, and HCR_EL2.IMO control IRQs.

This routing also controls the Exception level at which the EL1 CPU interface System registers that control and acknowledge interrupts are accessible. This applies to:

• ICC_IAR0_EL1, ICC_EOIR0_EL1, ICC_HPPIR0_EL1, ICC_BPR0_EL1, ICC_AP0R_EL1 and ICC_IGRPEN0_EL1. These are the registers that are associated with Group 0 interrupts.

• ICC_IAR1_EL1, ICC_EOIR1_EL1, ICC_HPPIR1_EL1, ICC_BPR1_EL1, ICC_AP1R_EL1 and ICC_IGRPEN1_EL1. These are the registers that are associated with Group 1 interrupts.

• ICC_SGI0R_EL1, ICC_SGI1R_EL1, ICC_ASGI1R_EL1, ICC_CTLR_EL1, ICC_DIR_EL1, ICC_PMR_EL1, and ICC_RPR_EL1. These are the Common registers.

When (SCR_EL3.NS == 1 || SCR_EL3.EEL2== 1) && (HCR_EL2.FMO ==1 || HCR_EL2.IMO == 1)), accesses at EL1 are virtual accesses. Virtual accesses to ICC_SGI0R_EL1, ICC_SGI1R_EL1, and ICC_ASGI1R_EL1 always generate a Trap exception that is taken to EL2. Where a Distributor supports two Security states a PE might not implement EL2 or EL3. Table 4-6 shows the configurations that are supported in these cases.

Table 4-6 Supported configurations when EL3 is not implemented

4.7 Enabling the distribution of interrupts

The following control bits enable and disable the distribution of interrupts:

• GICD_CTLR.EnableGrp1S.

• GICD_CTLR.EnableGrp1NS.

• GICD_CTLR.EnableGrp0.

The following control bits enable and disable the distribution of interrupt groups at the CPU interface:

• ICC_IGRPEN0_EL1.Enable for Group 0 interrupts.

• ICC_IGRPEN1_EL1.Enable for Group 1 interrupts.

Note

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

• ICC_IGRPEN1_EL3.{EnableGrp1S, EnableGrp1NS}.

Physical LPIs are enabled by a write to GICR_CTLR.EnableLPIs.

4.7.1 Enabling individual interrupts

PPIs

PPIs can be enabled and disabled by writing to GICR_ISENABLER0 and GICR_ICENABLER0 when affinity routing is enabled for the Security state of the interrupt. Individual PPIs can also be enabled and disabled by writing to GICD_ISENABLER and GICD_ICENABLER. n = 0 for PPIs, if legacy operation for physical interrupts is supported and configured.

PPIs in the optional, extended PPI range are enabled and disabled by writing to GICR_ISENABLERE, and GICD_ICENABLERE.

SPIs

Individual SPIs can be enabled and disabled by writing to GICD_ISENABLER and GICD_ICENABLER. n >0 for SPIs.

SPIs in the optional, extended SPI range are enabled and disabled by writing to GICD_ISENABLERE, and GICD_ICENABLERE.

SGIs

SGIs can be enabled and disabled by writing to GICR_ISENABLER0 and GICR_ICENABLER0 when affinity routing is enabled. Individual SGIs can also be enabled and disabled by writing to GICD_ISENABLER and GICD_ICENABLER. n = 0 for SGIs, if legacy operation for physical interrupts is supported and configured.

Note Whether SGIs are permanently enabled, or can be enabled and disabled by writes to GICR_ISENABLER0 and GICR_ICENABLER0, is IMPLEMENTATION DEFINED.

LPIs

Individual LPIs can be enabled by setting the enable bits programmed in the LPI Configuration table. For more information about enabling LPIs using the LPI Configuration tables, see LPI Configuration tables.

4.7.2 Interaction of group and individual interrupt enables

The GICD_* and GICR_* registers determine, at any moment in time, the highest priority pending interrupt that the hardware is aware of for each target PE. This interrupt is presented to the CPU interface of a PE to evaluate whether it is to be signaled to the PE. The enabling of the interrupts affects this evaluation as follows:

• A pending interrupt that is individually disabled in the GICD_* or GICR_* registers is not one which is considered in the determination of the highest priority pending interrupt, and so cannot be signaled to the PE.

• A pending interrupt that is individually enabled in the GICD_* or GICR_* registers, but is a member of a group that is disabled in GICD_CTLR, is not one that is considered in the determination of the highest priority pending interrupt, and so cannot be signaled to the PE.

• A pending 1 of N interrupt that is individually enabled in the GICD_* registers and is a member of a group that is enabled in GICD_CTLR, but is a member of a group that is disabled in ICC_IGRPEN0_EL1, ICC_IGRPEN1_EL1, or ICC_IGRPEN1_EL3 for a PE, cannot be selected for that PE. Such an interrupt is not considered in the determination of the highest priority pending interrupt and so cannot be signaled to the PE.

• For a pending direct interrupt that is individually enabled in the GICD_* or GICR_* registers and is a member of a group that is enabled in GICD_CTLR, but is a member of a group that is disabled in ICC_IGRPEN0_EL1, ICC_IGRPEN1_EL1, or ICC_IGRPEN1_EL3, it is IMPLEMENTATION DEFINED whether or not the interrupt is considered in the determination of the highest priority pending interrupt. If it is determined to be the highest priority pending interrupt, the interrupt is not signaled to the PE, but will mask a lower priority pending interrupt that is a member of a group that is enabled in ICC_IGRPEN0_EL1, ICC_IGRPEN1_EL1, or ICC_IGRPEN1_EL3.

LPIs are enabled individually in the LPI Configuration tables, see LPI Configuration tables.

4.7.3 Effect of disabling interrupts

Disabling an interrupt by writing to the appropriate GICD_ICENABLER or to GICR_ICENABLER0, or by writing to the LPI Configuration tables, does not prevent that interrupt from changing state, for example from becoming pending. When GICR_CTLR.EnableLPIs == 0, LPIs are never set pending.

If GICD_CTLR.EnableGrp0, GICD_CTLR.EnableGrp1S, and GICD_CTLR.EnableGrp1NS are all cleared to 0, it is IMPLEMENTATION DEFINED whether:

• An edge-triggered interrupt signal moves the interrupt to the pending state.

• SGIs can be set pending by writing to GICD_SGIR, ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1.

If an interrupt is pending on a CPU interface when the corresponding GICD_CTLR.EnableGrp0, GICD_CTLR.EnableGrp1NS, or GICD_CTLR.EnableGrp1S bit is written from 1 to 0, then the interrupt must be retrieved from the CPU interface.

Note This might have no effect on the forwarded interrupt if it has already been activated.

If an interrupt is pending on a CPU interface when software writes ICC_IGRPEN0_EL1.Enable, ICC_IGRPEN0_EL1, ICC_IGRPEN1_EL1.Enable, or ICC_IGRPEN1_EL3.Enable from 1 to 0, the interrupt must be released by the CPU interface to allow the Distributor to forward the interrupt to a different PE.

4.8 Interrupt prioritization

This section describes interrupt prioritization in the GIC architecture. Prioritization describes the:

• Configuration and control of interrupt priority.

• Order of execution of pending interrupts.

• Determination of when interrupts are visible to a target PE, including:

  • Interrupt priority masking.

  • Priority grouping.

  • Preemption of an active interrupt.

Software configures interrupt prioritization in the GIC by assigning a priority value to each interrupt source. Priority values are an 8-bit unsigned binary number. A GIC implementation that supports two Security states must implement a minimum of 32 and a maximum of 256 levels of physical priority. A GIC implementation that supports only a single Security state must implement a minimum of 16 and a maximum of 256 levels of physical priority. If the GIC implements fewer than 256 priority levels, the low-order bits of the priority fields are RAZ/WI. This means that the number of implemented priority field bits is IMPLEMENTATION DEFINED, in the range 4-8. Table 4-7 shows the relation between the priority field bits and the number of priority levels supported by an implementation.

Table 4-7 Effect of not implementing some priority field bits

In the GIC prioritization scheme, lower numbers have higher priority. This means that the lower the assigned priority value, the higher the priority of the interrupt. Priority field value 0 always indicates the highest possible interrupt priority, and the lowest priority value depends on the number of implemented priority levels.

The GICD_IPRIORITYR registers hold the priority value for each supported SPI. An implementation might reserve an SPI for a particular purpose and assign a fixed priority to that interrupt, meaning the priority value for that interrupt is read-only. For other SPIs the GICD_IPRIORITYR registers can be written by software to set the interrupt priorities. It is IMPLEMENTATION DEFINED whether a write to GICD_IPRIORITYR changes the priority of any active SPI.

In a multiprocessor implementation, the GICR_IPRIORITYR and GICR_IPRIORITYRE registers define the interrupt priority of each SGI and PPI INTID independently for each target PE.

LPI Configuration tables and LPI Pending tables in memory store LPI priority information and pending status, see LPI Configuration tables and LPI Pending tables.

The GIC security model provides Secure and Non-secure accesses to the interrupt priority settings.The Non-secure accesses can configure interrupts only in the lower priority half of the supported priority values. Therefore, if the GIC implements 32 priority values, Non-secure accesses see only 16 priority values. See Software accesses of interrupt priority for more information.

To determine the number of priority bits implemented for SPIs, software can write 0xFF to a writable GICD_IPRIORITYR priority field and read back the value stored.

To determine the number of priority bits implemented for SGIs and PPIs, software can write 0xFF to the GICR_IPRIORITYR priority fields, and read back the value stored.

The GIC architecture does not require all PEs in the system to use the same number of priority bits to control interrupt priority. In a multiprocessor implementation, ICC_CTLR_EL1.PRIbits and ICC_CTLR_EL3.PRIbits indicate the number of priority bits implemented, independently for each target PE.

Note Arm recommends that implementations support the same number of priority bits for each PE.

For information about the priority range supported for virtual interrupts, see Chapter 6 Virtual Interrupt Handling and Prioritization .

Note Arm recommends that, before checking the priority range in this way:

• For a peripheral interrupt, software first disables the interrupt.

• For an SGI, software first checks that the interrupt is inactive.

If, on a particular CPU interface, multiple pending interrupts have the same priority, and have sufficient priority for the interface to signal them to the PE, it is IMPLEMENTATION DEFINED how the interface selects which interrupt to signal.

GICv3 guarantees that the highest priority, unmasked, enabled interrupt will be delivered to a target PE in finite time.

There is no guarantee that higher priority interrupts will always be taken before lower priority interrupts, although this will generally be the case.

The remainder of this section describes:

• Non-secure accesses to register fields for Secure interrupt priorities .

• Priority grouping.

• System register access to the Active Priorities registers.

• Preemption.

• Priority masking.

• Software accesses of interrupt priority.

• Changing the priority of enabled PPIs, SGIs, and SPIs.

4.8.1 Non-secure accesses to register fields for Secure interrupt priorities

When GICD_CTLR.DS == 0, the GIC supports the use of:

• Group 0 interrupts as Secure interrupts.

• Secure Group 1 interrupts.

• Non-secure Group 1 interrupts.

In order to support the Armv8 Security model the register fields associated with Secure interrupts are RAZ/WI for Non-secure accesses. In addition, the following rules apply:

For Non-secure access to a priority field in GICx_IPRIORITYR:

If the priority field corresponds to a Non-secure Group 1 interrupt in Software accesses of interrupt priority:

• For SPIs, the priority field is determined by GICD_IPRIORITYR or GICD_IPRIORITYRE.

• For PPIs and SGIs, the priority field is determined by GICR_IPRIORITYR or GICR_IPRIORITYRE.

For Non-secure access to ICC_PMR_EL1 and ICC_RPR_EL1 when SCR_EL3.FIQ == 1:

• If the current priority mask value is in the range of 0x00-0x7F:

  • A read access returns the value 0x00.

• The GIC ignores a write access to ICC_PMR_EL1.

• If the current priority mask value is in the range of 0x80-0xFF:

• A read access returns the Non-secure read of the current value.

• A write access to ICC_PMR_EL1 succeeds, based on the Non-secure read of the priority mask value written to the register.

Note

This means a Non-secure write cannot set a priority mask value in the range of 0x00-0x7F.

For Non-secure access to ICC_PMR_EL1 and ICC_RPR_EL1 when SCR_EL3.FIQ == 0:

The Secure, unshifted view applies.

AArch64 functions provides pseudocode that describes accesses to the following System registers in a GIC that supports two Security states:

• ICC_PMR_EL1.

• ICC_RPR_EL1.

4.8.2 Priority grouping

Priority grouping uses the following Binary Point Registers :

• ICC_BPR0_EL1 for Group 0 interrupts. This register is available in all GIC implementations.

• A Non-secure copy of ICC_BPR1_EL1 for Non-secure Group 1 interrupts. If an implementation supports two Security states, there is a Secure and a Non-secure copy of this register. If an implementation supports only one Security state, there is only one copy of this register

• A Secure copy of ICC_BPR1_EL1 for Secure Group 1 interrupts. This register is available only in a GIC implementation that supports two Security states.

The Binary Point Registers split a priority value into two fields, the group priority and the subpriority . When determining preemption, all interrupts with the same group priority are considered to have the same priority, regardless of the subpriority.

Where multiple pending interrupts have the same group priority, the GIC uses the subpriority field to resolve the priority within a group. Where two or more pending interrupts in a group have the same subpriority, how the GIC selects between the interrupts is implementation specific.

The GIC uses the group priority field to determine whether a pending interrupt has sufficient priority to preempt execution on a PE, as follows:

• The value of the group priority field for the interrupt must be lower than the value of the running priority of the PE. The running priority is the group priority of the highest priority active interrupt that has not received a priority drop on that PE.

• The value of the priority for the interrupt must be lower than the value of its priority mask.

ICC_BPR0_EL1 determines the priority grouping of Group 0 interrupts:

• When ICC_CTLR_EL3.CBPR_EL1S is set to 1, ICC_BPR0_EL1 also determines the priority grouping of Secure Group 1 interrupts.

• When ICC_CTLR_EL3.CBPR_EL1NS is set to 1, ICC_BPR0_EL1 also determines the priority grouping of Non-secure Group 1 interrupts

ICC_BPR1_EL1 determines the priority of Group 1 interrupts:

• When ICC_CTLR_EL3.CBPR_EL1S is cleared to 0, the Secure copy of ICC_BPR1_EL1 determines the priority grouping of Secure Group 1 interrupts.

• When ICC_CTLR_EL3.CBPR_EL1NS is cleared to 0, the Non-secure copy of ICC_BPR1_EL1 determines the priority grouping of Non-secure Group 1 interrupts. Table 4-8 shows the split of the interrupt priority fields for Secure ICC_BPR1_EL1.

Table 4-8 Secure ICC_BPR1_EL1 Binary Point when CBPR == 0

Table 4-9 shows the split of the interrupt priority fields for Non-secure ICC_BPR1_EL1.

Table 4-9 Non-secure ICC_BPR1_EL1 Binary Point when CBPR == 0

Table 4-10 shows the split of the interrupt priority fields for ICC_BPR0_EL1.

Table 4-10 ICC_BPR0_EL1 Binary Point for Group 1 interrupts when CBPR == 1, or for Group 0 interrupts

a. If a Non-secure write sets the priority value field for a Non-secure interrupt then bit[7] == 1.

The minimum binary point value that is supported depends on the IMPLEMENTATION DEFINED number of priority bits, as shown in Table 4-11.

Table 4-11 Minimum binary point value support

The number of priority bits that are implemented is indicated by ICC_CTLR_EL1.PRIBits and ICC_CTLR_EL3.PRIBits.

In a GIC that supports two Security states, when:

• ICC_CTLR_EL3.CBPR_EL1S == 1:

  • Writes to ICC_BPR1_EL1 at Secure EL1 modify ICC_BPR0_EL1.

  • Reads from ICC_BPR1_EL1 at Secure EL1 return the value of ICC_BPR0_EL1.

• ICC_CTLR_EL3.CBPR_EL1NS == 1:

  • Non-secure writes to ICC_BPR1_EL1 are ignored.

  • Non-secure reads from ICC_BPR1_EL1 return ICC_BPR0_EL1 + 1 saturated to 0b111.

Note

• When an interrupt is using Non-secure ICC_BPR1_EL1, the effective binary point value is that stored in the register, minus one, as shown in Table 4-9. This means that software with no awareness of the effects of interrupt grouping and where two Security states are supported, sees the same priority grouping mechanism, regardless of whether it is running on a PE that is in Secure state or in Non-secure state.

• Priority grouping always operates on the full priority, which is the value that would be visible to a Secure read. This is different from the value that is visible to a Non-secure read of the priority value corresponding to a Non-secure interrupt. See Figure 4-8 and Figure 4-9.

• When EL3 is using AArch32, and ICC_MCTLR.CBPR_EL1S == 1, accesses to ICC_BPR1 at EL3 and not in Monitor mode access the state of ICC_BPR0.

Pseudocode

The following pseudocode indicates the group priority of the interrupt.

// GroupBits()
// ===========
// Returns the priority group field for the current BPR value for the group

bits(8) GroupBits(bits(8) priority, IntGroup group)
    bit cbpr_G1NS = if HaveEL(EL3) then ICC_CTLR_EL3.CBPR_EL1NS else ICC_CTLR_EL1.CBPR;
    bit cbpr_G1S = if HaveEL(EL3) then ICC_CTLR_EL3.CBPR_EL1S else '0';

    if (group == IntGroup_G0 ||
         (group == IntGroup_G1NS && cbpr_G1NS == '1') ||
         (group == IntGroup_G1S && cbpr_G1S == '1')) then
         bpr = UInt(ICC_BPR0_EL1.BinaryPoint);
    elsif group == IntGroup_G1S then
         bpr = UInt(ICC_BPR1_EL1S.BinaryPoint);
    else
         bpr = UInt(ICC_BPR1_EL1NS.BinaryPoint) -1;

    mask = Ones(7-bpr):Zeros(bpr+1);

    return priority AND mask;

4.8.3 System register access to the Active Priorities registers

Physical Group 0 and Group 1 interrupts access different Active Priorities registers, depending on the interrupt group.

For Group 0 interrupts, these registers are ICC_AP0R_EL1, where n = 0-3:

• If 32 or fewer priority levels are implemented, accesses to ICC_AP0R_EL1, where n = 1-3, are UNDEFINED.

• If more than 32 and fewer than 65 priority levels are implemented, accesses to ICC_AP0R_EL1, where n = 2-3, are undefined.

For Group 1 interrupts, these registers are ICC_AP1R_EL1, where n= 0-3:

• If 32 or fewer priority levels are implemented, accesses to ICC_AP1R_EL1, where n = 1-3, are undefined.

• If more than 32 and fewer than 65 priority levels are implemented, accesses to ICC_AP1R_EL1, where n = 2-3, are undefined.

The content of ICC_AP0R_EL1, Secure ICC_AP1R_EL1, and Non-secure ICC_AP1R_EL1 is IMPLEMENTATION DEFINED. However, the value 0x00000000 must be consistent with no priorities being active.

Writing any value other than the last read value, or 0x00000000, to these registers can cause:

• Interrupts that would otherwise preempt execution to not preempt execution.

• Interrupts that otherwise would not preempt execution to preempt execution.

A Non-secure write to Non-secure ICC_AP1R_EL1 cannot prevent the correct prioritization and cannot prevent the forwarding of interrupts of higher priority than those in the Non-secure priority range.

Writes to these registers in any order other than the following can result in UNPREDICTABLE behavior:

1. ICC_AP0R_EL1.

2. Secure ICC_AP1R_EL1.

3. Non-secure ICC_AP1R_EL1.

Note An ISB is not required between each write to ICC_AP0R_EL1, Secure ICC_AP1R_EL1, and Non-secure ICC_AP1R_EL1.

Table 4-12 shows an implementation of ICC_AP0R_EL1.

Table 4-12 Group 0 Active Priorities Register implementation

Table 4-13 shows an implementation of ICC_AP1R_EL1.

Table 4-13 Group 1 Active Priorities Register implementation

4.8.4 Preemption

A CPU interface supports signaling of higher priority pending interrupts to a target PE before an active interrupt completes. A pending interrupt is only signaled if both:

• Its priority is higher than the priority mask for that CPU interface. See Priority masking.

• Its group priority is higher than that of the running priority on the CPU interface. See Priority grouping for more information.

Preemption occurs at the time when the PE takes the new interrupt, and starts handling the new interrupt instead of the previously active interrupt or the currently running process. When this occurs, the initial active interrupt is said to have been preempted .

Note The value of the I or F bit in the Process State, PSTATE, and the Exception level and the interrupt routing controls in software and hardware, determine whether the PE responds to the signaled interrupt by taking the interrupt. For more information, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

For more information about enabling interrupts, see Enabling the distribution of interrupts.

Preemption level control

ICC_BPR0_EL1 determines whether a Group 0 interrupt is signaled to the PE for possible preemption. In addition:

• When ICC_CTLR_EL3.CBPR_EL1NS == 1, ICC_BPR0_EL1 also determines whether a Non-secure Group 1 interrupt is signaled to the PE for possible preemption.

• When ICC_CTLR_EL3.CBPR_EL1S == 1, ICC_BPR0_EL1 also determines whether a Secure Group 1 interrupt is signaled to the PE for possible preemption.

ICC_BPR1_EL1 determines whether a Group 1 interrupt is signaled to the PE for possible preemption. The Non-secure copy of this register is used for Non-secure Group 1 interrupts. The Secure copy is used for Secure Group 1 interrupts.

When ICC_CTLR_EL3.CBPR_EL1NS is set to 1:

• EL3 can write to ICC_BPR1_EL1(NS). When EL3 is using AArch64 state, accesses to ICC_BPR1_EL1(NS) from EL3 are not affected by ICC_CTLR_EL3.CBPR_EL1NS.

  • When EL3 is using AArch32 state, accesses to ICC_BPR1_EL1(NS) from Monitor mode are not affected by ICC_CTLR_EL3.CBPR_EL1NS.

• Non-secure writes to ICC_BPR1_EL1 at EL1 or EL2 are ignored.

• Non-secure reads of ICC_BPR1_EL1 at EL1 or EL2 return the value of ICC_BPR0_EL1 +1, saturating at 7.

When ICC_CTLR_EL3.CBPR_EL1S is set to 1:

• Secure reads of ICC_BPR1_EL1 return the value of ICC_BPR0_EL1.

• Secure writes to ICC_BPR1_EL1 update ICC_BPR0_EL1.

4.8.5 Priority masking

The Priority Mask Register for a CPU interface, ICC_PMR_EL1, defines a priority threshold for the target PE. The GIC only signals pending interrupts that have a higher priority than this priority threshold to the target PE. A value of zero, the register reset value, masks all interrupts from being signaled to the associated PE. The GIC does not use priority grouping when comparing the priority of a pending interrupt with the priority threshold.

The GIC always masks an interrupt that has the lowest supported priority. This priority is sometimes referred to as the idle priority.

Note Writing 0xFF to ICC_PMR_EL1 always sets it to the lowest supported priority. Table 4-7 shows how the lowest supported priority varies with the number of implemented priority bits.

If the GIC provides support for two Security states, ICC_PMR_EL1 is RAZ/WI to Non-secure accesses, if bit[7] == 0. During normal operation, software executing in Non-secure state does not access ICC_PMR_EL1when it is programmed with such a value.

For information that relates to different GIC configurations, see Non-secure accesses to register fields for Secure interrupt priorities.

4.8.6 Software accesses of interrupt priority

This section describes Secure and Non-secure reads of interrupt priority, and the relationship between them. It also describes writes to the priority value fields.

Note This section applies to any GIC implementation that supports two Security states.

When a PE reads the priority value of a Non-secure Group 1 interrupt, the GIC returns either the Secure or the Non-secure read of that value, depending on whether the access is Secure or Non-secure. The GIC implements a minimum of 32 and a maximum of 256 priority levels. This means it implements 5-8 bits of the 8-bit priority value fields in the appropriate GICR_IPRIORITYR and GICD_IPRIORITYR register. All of the implemented priority bits can be accessed by a Secure access, and unimplemented low-order bits of the priority fields are RAZ/WI. Figure 4-5 shows the Secure read of a priority value field for an interrupt. The priority value stored in the Distributor is equivalent to the Secure read.

Figure 4-5 Secure read of the priority field for any interrupt

In this view:

• Bits H-D are the bits that the GIC must implement, corresponding to 32 priority levels.

• Bits C-A are the bits the GIC might implement. They are RAZ/WI if not implemented.

• The GIC must implement bits H-A to provide the maximum 256 priority levels.

For Non-secure accesses, the GIC supports half the priority levels it supports for Secure accesses, which means a minimum of 16 priority levels. Figure 4-6 shows the Non-secure view of a priority value field for a Non-secure Group 1 interrupt.

Figure 4-6 Non-secure read of the priority field for a Non-secure Group 1 interrupt In this read:

• Bits G-D are the bits that the GIC must implement, corresponding to 16 priority levels.

• Bits C-A are the bits the GIC might implement, that are RAZ/WI if not implemented.

• The GIC must implement bits G-A to provide the maximum 128 priority levels.

• Bit [0] is RAZ/WI.

The Non-secure read of a priority value does not show how the value is stored in the registers in the Distributor. For Non-secure writes to a priority field of a Non-secure Group 1 interrupt, before storing the value:

• The value is right-shifted by one bit.

• Bit [7] of the value is set to 1.

This translation means the priority value for the Non-secure Group 1 interrupt is in the bottom half of the priority range.

A Secure read of the priority value for an interrupt returns the value stored in the Distributor. Figure 4-7 shows this Secure read of the priority value field for a Non-secure Group 1 interrupt that has had its priority value field set by a Non-secure access, or has had a priority value with bit[7] == 1 set by a Secure access:

Figure 4-7 Secure read of the priority field for a Non-secure Group 1 interrupt A Secure write to the priority value field for a Non-secure Group 1 interrupt can set bit [7] to 0. If a Secure write sets bit[7] to 0:

• A Non-secure read returns the value GFEDCBA0.

• A Non-secure write can change the value of the field, but only to a value that has bit [7] set to 1 for the Secure read of the field.

Note

• This behavior of Non-secure accesses applies only to the priority value fields in GICR_IPRIORITYR and GICD_IPRIORITYR, as appropriate:

  • If the Priority field in ICC_PMR_EL1 holds a value with bit [7] == 0, then the field is RAZ/WI for Non-secure accesses.

  • If the Priority field in ICC_RPR_EL1 holds a value with bit [7] == 0, then the field is RAZ for Non-secure reads.

• Arm does not recommend setting bit[7] to 0 for a Non-secure Group 1 interrupt in this way because it places the interrupt in the wrong half of the priority range for maintenance by non-secure code.

Figure 4-8 shows the relationship between the reads of the priority value fields for Non-secure Group 1 interrupts.

Figure 4-9 shows how software reads of the interrupt priorities from Secure and Non-secure accesses relate to the priority values held in the Distributor, and to the interrupt values that are visible to Secure and Non-secure accesses. Figure 4-9 applies to a GIC that implements the maximum range of priority values.

Table 4-14 shows how the number of priority value bits implemented by the GIC affects the Secure and Non-secure reads of the priority of a Non-secure Group 1 interrupt.

Note Software executing in Non-secure state has no visibility of the priority settings of Group 0 interrupts, or where applicable, of Secure Group 1 interrupts.

Table 4-14 Effect of not implementing some priority field bits, two Security states

| Implemented priority bits, as seen by a Secure read [7:0] | Possible priority field values, for a Non-secure Group 1 interrupt Secure read Non-secure read | |—|— 0xFF-0x00(255-0), all values 0xFE-0x00(254-0), even values only | | [7:1] | 0xFE-0x00(254-0), even values only 0xFC-0x00(252-0), in steps of 4 | | [7:2] | 0xFC-0x00(252-0), in steps of 4 0xF8-0x00(248-0), in steps of 8 | | [7:3] | 0xF8-0x00(248-0), in steps of 8 0xF0-0x00(240-0), in steps of 16 |

This model for the presentation of priority values ensures software written to operate with an implementation of this GIC architecture functions as intended regardless of whether the GIC provides support for two Security states. However, programmers must ensure that software assigns the appropriate priority levels to the Group 0 and Group 1 interrupts.

Note To control priority values, Arm strongly recommends that:

• For a Group 0 interrupt, software sets bit[7] of the priority value field to 0.
• If using a Secure write to set the priority of a Non-secure Group 1 interrupt, software sets bit[7] of the priority value field to 1.

This ensures that all Group 0 and, if applicable, Secure Group 1 interrupts have higher priorities than all Non-secure Group 1 interrupts. However, a system might have requirements that cannot be met with this scheme.

Table 4-15 shows an example priority allocation scheme that ensures:

• Some Group 0 interrupts have higher priority than any other interrupts.

• Some Secure Group 1 interrupts have higher priority than any Non-secure Group 1 interrupt.

Table 4-15 Example priority allocation

• Software might not be aware that the GIC supports two Security states, and therefore might not know whether it is making Secure or Non-secure accesses to GIC registers. However, for any implemented interrupt, software can write 0xFF to the corresponding GICR_IPRIORITYR priority value field, and then read back the value stored in the field to determine the supported interrupt priority range. Arm recommends that, before checking the priority range in this way:

  • For a peripheral interrupt, software first disables the interrupt.

• For an SGI, software first checks that the interrupt is inactive.

4.8.7 Changing the priority of enabled PPIs, SGIs, and SPIs

If software writes to the GICD_IPRIORITYR, GICD_IPRIORITYRE, GICR_IPRIORITYR and GICR_IPRIORITYRE registers of an enabled interrupt while the interrupt is pending, it is IMPLEMENTATION DEFINED whether the GIC uses the old value or the new value. The GIC ensures that no interrupt is handled more than once, and that no interrupt is lost. The effect of the write must be visible in finite time. 4.8 Interrupt prioritization

Chapter 5: Locality-specific Peripheral Interrupts and the ITS

This chapter describes Locality-specific Peripheral Interrupts (LPIs) and the Interrupt Translation Service (ITS). It contains the following sections:

• LPIs.

• The Interrupt Translation Service.

• ITS commands.

• Common ITS pseudocode functions.

• ITS command error encodings.

• ITS power management.

5.1 LPIs

Locality-specific Peripheral Interrupts (LPIs) are edge-triggered message-based interrupts that can use an Interrupt Translation Service (ITS), if it is implemented, to route an interrupt to a specific Redistributor and connected PE. GICv3 provides two types of support for LPIs. LPIs can be supported either:

• Using the ITS to translate an EventID from a device into an LPI INTID. For more information about EventIDs, see The Interrupt Translation Service.

• By forwarding an LPI INTID directly to the Redistributors, using GICR_SETLPIR.

An implementation must support only one of these methods.

Note

The following registers are mandatory in an implementation that supports LPIs but does not include an ITS:

• GICR_INVLPIR.

• GICR_INVALLR.

• GICR_SYNCR.

Support for these registers is IMPLEMENTATION DEFINED in implementations that do include an ITS.

These registers control physical LPIs in a system that does not include an ITS:

• GICR_SETLPIR.

• GICR_CLRLPIR.

In an implementation that includes LPIs, at least 8192 LPIs are supported. For this reason, the configuration of each interrupt, and the pending information for each interrupt, is held in tables in memory, rather than in registers, and the tables are pointed to by registers held in the Redistributors.

Note

• Arm expects that an implementation will cache parts of the tables in the Redistributors to reduce latency and memory traffic. The form of these caches is IMPLEMENTATION DEFINED.

• The addresses for the LPI tables are in the Non-secure physical address space.

Figure 5-1 shows the generation of LPIs in an implementation that includes at least one ITS.

Figure 5-1 Triggering LPIs in an implementation with an ITS

Note In Figure 5-1, the ITS channel to the Redistributors is IMPLEMENTATION DEFINED.

Figure 5-2 shows the generation of LPIs in an implementation without an ITS. 5.1 LPIs

Message-based interrupts

• LPIs are only supported when affinity routing is enabled for Non-secure state.

• LPIs are always Non-secure Group 1 interrupts.

When GICD_CTLR.DS == 1:

• LPIs are only supported when affinity routing is enabled.

• LPIs are always Group 1 interrupts.

There is a single global physical LPI space so that LPIs can be moved between all Redistributors. Software programs the size of the single global physical LPI space using GICR_PROPBASER.IDbits.

Note The size of the physical LPI space is limited to the maximum size that an implementation supports, which is defined in GICD_TYPER.IDbits.

For a given Redistributor, LPI configuration and state are maintained in two tables in memory, described in the following sections:

• LPI Configuration tables.

• LPI Pending tables. If a Redistributor supports physical LPIs, it has:

• LPI priority and enable bits programmed in the LPI Configuration table. The address of the LPI Configuration table is defined by GICR_PROPBASER. If GICR_PROPBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE. See LPI Configuration tables for more information.

• Memory-backed storage for LPI pending bits in an LPI Pending table. This table is specific to a particular Redistributor. The address of the LPI Pending table is defined by GICR_PENDBASER. If GICR_PENDBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE.

GICR_PROPBASER.IDBits sets the size of the ID space, and thereby the number of entries in the LPI Configuration table and the corresponding LPI Pending table.

Physical LPIs are enabled by a write to GICR_CTLR.EnableLPIs.

Note

When LPIs are disabled at the Redistributor interface, that is when GICR_CTLR.EnableLPIs == 0, LPIs cannot become pending. An attempt to make an LPI pending in this situation has no effect, and the LPI is lost. This differs from disabling SGIs, PPIs, and SPIs, which prevents only the signaling of the interrupt to the CPU interface.

GICv4 introduces equivalent tables for handling virtual LPIs with addresses referenced in GICR_VPROPBASER and GICR_VPENDBASER.

In GICv4, virtual LPIs are enabled by a write to GICR_VPENDBASER.Valid.

5.1.1 LPI Configuration tables

LPI configuration is global. Whether a GIC supports Redistributors that point at different copies of the LPI Configuration table is IMPLEMENTATION DEFINED.

It is IMPLEMENTATION DEFINED whether GICR_PROPBASER can be set to different values on different Redistributors. GICR_TYPER.CommonLPIAff indicates which Redistributors must have GICR_PROPBASER set to the same value whenever GICR_CTLR.EnableLPIs == 1.

An implementation can treat all copies of GICR_PROPBASER that are required to have the same value as accessing common state.

Setting different values in different copies of GICR_PROPBASER on Redistributors that are required to use a common LPI Configuration table when GICR_CTLR.EnableLPIs == 1 leads to UNPREDICTABLE behavior.

If GICR_PROPBASER is programmed to different values on different Redistributors, it is IMPLEMENTATION DEFINED which copy or copies of GICR_PROPBASER are used when the GIC reads the LPI Configuration tables. However, the copy or copies that are used will correspond to a Redistributor on which GICR_CTLR.EnableLPIs == 1.

To avoid unpredictable behavior, software must ensure that all copies of the LPI Configuration tables are identical, and all changes are globally observable, whenever:

• GICR_CTLR.EnableLPIs is written from 0 to 1 on any Redistributor.

• GICR_INVLPIR and GICR_INVALLR are written on any Redistributor with GICR_CTLR.EnableLPIs == 1, if direct LPIs are supported.

• The INV and INVALL command is executed by an ITS, in an implementation that includes at least one ITS.

An LPI Configuration table in memory stores entries containing configuration information for each LPI, where:

• GICR_PROPBASER specifies a 4KB aligned physical address. This is the LPI Configuration table base address.

• For any LPI N, the location of the table entry is defined by (base address + (N – 8192)).

To change the configuration of an interrupt, software writes to the LPI Configuration tables and then issues the INV or INVALL command. In implementations that do not include an ITS, software writes to GICR_INVALLR or GICR_INVLPIR. 5.1 LPIs

The LPI Configuration table contains an 8-bit entry for each LPI. Figure 5-3 shows the LPI Configuration table entry format.

7 2 1 0
Priority
RES1
Enable Figure 5-3 LPI Configuration table entry

Table 5-1 shows the LPI Configuration table entry bit assignments.

Table 5-1 LPI Configuration table entry bit assignments

Caching

A Redistributor can cache the information from the LPI Configuration tables pointed to by GICR_PROPBASER, when GICR_CTLR.EnableLPI == 1, subject to all of the following rules:

• Whether or not one or more caches are present is IMPLEMENTATION DEFINED. Where at least one cache is present, the structure and size is IMPLEMENTATION DEFINED.

• An LPI Configuration table entry might be allocated into the cache at any time.

• A cached LPI Configuration table entry is not guaranteed to remain in the cache.

• A cached LPI Configuration table entry is not guaranteed to remain incoherent with memory.

• A change to the LPI configuration is not guaranteed to be visible until an appropriate invalidation operation has completed:

  • If one or more ITS is implemented, invalidation is performed using the INV or INVALL command. A SYNC command completes the INV and INVALL commands.

• If no ITS is implemented, invalidation is performed by writing to GICR_INVALLR or GICR_INVLPIR.

If there is no Redistributor with GICR_CTLR.EnableLPIs == 1, the GIC has no cached LPI Configuration table entries.

5.1.2 LPI Pending tables

Software configures the LPI Pending tables, using the implemented range of valid LPI INTIDs, by writing to GICR_PENDBASER. This register provides the base address of the LPI Pending table for physical LPIs.

Each Redistributor maintains entries in a separate LPI Pending table that indicates the pending state of each LPI when GICR_CTLR.EnableLPIs == 1 in the Redistributor:

0 The LPI is not pending. 1 The LPI is pending.

For a given LPI:

• The corresponding byte in the LPI Pending table is (base address + (N / 8)).

• The bit position in the byte is (N MOD 8).

An LPI Pending table that contains only zeros, including in the first 1KB, indicates that there are no pending LPIs.

The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED. However, if the first 1KB of the LPI Pending table and the rest of the table contain only zeros, this must indicate that there are no pending LPIs.

The first 1KB of memory for the LPI Pending tables must contain only zeros on initial allocation, and this must be visible to the Redistributors, or else the effect is unpredictable.

During normal operation, the LPI Pending table is maintained solely by the Redistributor.

Behavior is UNPREDICTABLE if software writes to the LPI Pending tables while GICR_CTLR.EnableLPIs == 1. When GICR_CTLR.EnableLPIs is cleared to 0, behavior is UNPREDICTABLE if the LPI Pending table is written before GICR_CTLR.RWP reads 0.

Redistributors that are required to share a common LPI Configuration table, as indicated by GICR_TYPER.CommonLPIAff, might treat the OuterCache, Shareability, or InnerCache fields of GICR_PENDBASER as accessing common state.

Having the OuterCache, Shareability, or InnerCache fields of GICR_PENDBASER are programmed to different values on different Redistributors with GICR_CTLR.EnableLPIs == 1 in a system is unpredictable.

For physical LPIs, when GICR_CTLR.EnableLPIs is changed to 1, the Redistributor must read the pending status of the physical LPIs from the physical LPI Pending table.

Note

If GICR_PENDBASER.PTZ == 1, software guarantees that the LPI Pending table contains only zeros, including in the first 1KB. In this case hardware might not read any part of the table.

If GICR_CTLR.EnableLPIs is cleared to 0, then when GICR_CTLR.RWP reads as 0 there are no further accesses by the GIC to the LPI Pending table, and any caching of the LPI Pending table is invalidated. There is no guarantee that clearing GICR_CTLR.EnableLPIs causes the LPI Pending table to be updated in memory.

Note

If one or more ITS is implemented, Arm strongly recommends that all LPIs are mapped to another Redistributor before GICR_CTLR.EnableLPIs is cleared to 0.

For virtual LPIs, when GICR_CTLR.EnableLPIs ==1, and GICR_VPENDBASER.Valid is changed to 1, the Redistributor must read the pending status of the virtual LPIs from the virtual LPI Pending table.

Note

• If GICR_VPENDBASER.IDAI == 0, the software guarantees that the LPI Pending table was written out by the same GIC implementation, meaning that hardware can rely on the first 1KB of the table and might not read the entire table.

• If GICR_PROPBASER.IDbits is less than 0b1101 when GICR_CTLR.EnableLPIs == 1, the GIC might still access the IMPLEMENTATION DEFINED region of the LPI Pending table.

5.1.3 Virtual LPI Configuration tables and virtual LPI Pending tables

GICv4 uses the same concept of memory tables to hold the configuration and pending information for virtual LPIs. The format of these tables is the same as for physical LPIs.

5.2 The Interrupt Translation Service

The Interrupt Translation Service (ITS) translates an input EventID from a device, identified by its DeviceID, and determines:

1. The corresponding INTID for this input.

2. The target Redistributor and, through this, the target PE for that INTID.

For GICv3, the ITS performs this function for events that are translated into physical LPIs. LPIs can be forwarded to a Redistributor either by an ITS or by a direct write to GICR_SETLPIR. An implementation must support only one of these methods.

For GICv4, the ITS also performs this function for interrupts that are directly injected as virtual LPIs, and for GICV4.1, virtual SGIs.

An ITS has no effect on physical SGIs, SPIs, or PPIs.

The flow of the ITS translation is as follows:

1. The DeviceID selects a Device table entry (DTE) in the Device table that describes which Interrupt translation table (ITT) to use.

2. The EventID selects an Interrupt translation entry (ITE) in the ITT that describes:

   • For physical interrupts:

     • The output physical INTID.

     • The Interrupt collection number , ICID.

   • For virtual interrupts, in GICv4:

     • The output virtual INTID.

     • The vPEID.

     • A doorbell to use if the vPE is not scheduled.

3. For physical interrupts, ICID selects a Collection table entry in the Collection table (CT) that describes the target Redistributor, and therefore the target PE, to which the interrupt is routed.

4. For virtual interrupts, in GICv4, the vPEID selects a vPE table entry that describes the Redistributor that is currently hosting the target vPE to which the interrupt is routed.

The tables used in the translation process are described in more detail in the following sections:

• The ITS tables .

• The Device table.

• The Interrupt translation table.

• The Collection table.

• The vPE table.

These tables are created and maintained using the ITS commands described in ITS commands. GICv3 and GICv4 do not support direct access to the tables, and the tables must be configured using the ITS commands.

5.2.1 The ITS tables

Software provisions memory for the ITS private tables when the GIC provides a set of registers that permits the following features to be discovered:

• The number of private tables that are required.

• The size of each entry in each table.

• The type of each table.

Note

All ITS tables are in the Non-secure physical address space.

The state and configuration of the ITS tables is stored in a set of tables in memory. This memory is allocated by software before enabling the ITS. GITS_BASER specifies the base address and size of the ITS tables, and must be provisioned before the ITS is enabled.

The ITS tables have either a flat structure or a two-level structure. The structure is determined by GITS_BASER:

• 0 Flat table. In this case a contiguous block of memory is allocated for the table. The format of the table is IMPLEMENTATION DEFINED.

  • Behavior is UNPREDICTABLE if memory that is used for the ITS tables does not contain zeros at the time of the new allocation for use by the ITS.

• 1 Two-level table. In this case each entry in the level 1 table is 64 bits, and has the following format:

  • Bit[63] - Valid:

    • If this bit is cleared to 0, the PhysicalAddress field does not point to the base address of a level 2 table.

    • If this bit is set to 1, the PhysicalAddress field points to the base address of a level 2 table.

  • Bits[62:52] - RES 0.

  • Bits[51:N] - PhysicalAddress of the level 2 table. N is the number of bits that are required to specify the page size:

    • The size of the level 2 table is determined by GITS_BASER.Page_Size.

  • Bits[N-1:0] - RES 0. N is the number of bits that are required to specify the page size.

  • The level 1 table is indexed by the appropriate ID so that level 1 entry = ID/(Page Size / Entry Size).

Note This allows software to determine the level 2 table that must be allocated for a given CollectionID, DeviceID, or vPEID.

For level 1 table entries, when Valid == 0:

• If the Type field specifies a valid table type other than a Collection table, the ITS discards any writes to the level 2 table.

• If the Type field specifies the Collection table, and ICID is greater than or equal to the number indicated by GITS_TYPER.HCC, the ITS discards any writes to the level 2 table.

The format of the level 2 table is IMPLEMENTATION DEFINED.

Behavior is UNPREDICTABLE if:

• Memory that is used for the level 2 tables does not contain zeros at the time of the new allocation for use by the ITS.

• Multiple level 1 table entries with Valid == 1 point to the same level 2 table.

Note As part of restoring the state of the ITS from powerdown events, the registers that describe the table can point to tables that were previously populated by the ITS, and so might contain values other than zeros. The details of power management of the ITS are IMPLEMENTATION DEFINED. See ITS power management.

Figure 5-4 shows how these tables are used in the translation process.

When GITS_CTLR.Enabled is written from 0 to 1 behavior is UNPREDICTABLE if any of the following conditions are true:

• GITS_CBASER.Valid == 0.

• GITS_BASER.Valid == 0, for any GITS_BASER register where the Type field indicates Device.

• GITS_BASER.Valid == 0, for any GITS_BASER register where the Type field indicates collection and GITS_TYPER.HCC == 0.

• In GICv4, GITS_BASER.Valid == 0, for any GITS_BASER register where the Type field indicates a vPE.

Software access to the private ITS tables.

If GITS_BASER.Indirect == 0, behavior is UNPREDICTABLE if memory that is used for the ITS tables does not contain all zeros when first allocated to the ITS.

If GITS_BASER.Indirect == 1, behavior is unpredictable if memory that is used for a level 2 table does not contain all zeros when it is first allocated for use by the ITS.

When GITS_CTLR.Enabled == 0 and GITS_CTLR.Quiescent == 1:

• An implementation will not access the tables that are pointed to by any of the GITS_BASER registers.

When GITS_CTLR.Enabled == 1 or GITS_CTLR.Quiescent == 0:

• An implementation will not access a table that is pointed to by any GITS_BASER register for which GITS_BASER.Valid == 0.

• For a table that is pointed to by a GITS_BASER register for which GITS_BASER.Valid == 1 and GITS_BASER.Indirect == 0, behavior is UNPREDICTABLE if the table is written by software.

• For a table that is pointed to by a GITS_BASER register for which GITS_BASER.Valid == 1 and GITS_BASER.Indirect == 1:

  • Behavior is UNPREDICTABLE if any of the level 2 table entries are written by software.

  • An ITS will not cache any entry in the level 1 table where the valid bit is cleared to 0.

• Behavior is UNPREDICTABLE if any level 1 table entry where the valid bit set to 1 is written by software.

• A write to a level 1 table entry that changes the valid bit from 0 to 1 must be globally visible before software adds a command to the ITS command queue that relies on that entry. Otherwise it is UNKNOWN if the command will succeed or if it will be ignored.

5.2.2 Interrupt collections

In GICv3, the ITS considers all physical LPIs that it generates to be members of collections . The data that is associated with a collection can be held in the ITS, in external memory, or in both. The ITS supports collections that are held in memory if any of the GITS_BASER.Type == 0b100:

• When the ITS supports collections that are held in memory, the total number of collections that is supported is determined by the memory allocated by software:

• If GITS_BASER.Indirect == 0, the number of collections supported in memory can be calculated using the following formula:

((number of pages * page size) / entry size) The relevant values for this formula are indicated in GITS_BASER.Size, GITS_BASER.PageSize, and GITS_BASER.EntrySize.

• If GITS_BASER.Indirect == 1, the number of collections supported in memory can be calculated using the following formula:

(((number of pages in level 1 table * page size) /8) * (page size/entry size)). The relevant values for this formula are indicated in GITS_BASER.Size, GITS_BASER.PageSize, and GITS_BASER.EntrySize.

Note

Indirect tables allow sparse allocations, so not all ICIDs in the supported range might be usable.

• Where collections are held in both the ITS and external memory, the total number of collections is indicated by GITS_TYPER.CCT.

When GITS_TYPER.HCC!= 0:

• Collections with identifiers in the range {0… GITS_TYPER.HCC-1} are held in the ITS.

• Collections with identifiers in the range greater than that indicated in GITS_TYPER.HCC are held in external memory, if this is supported.

When GITS_TYPER.HCC == 0:

• The ITS must support collections in external memory, and all collections are held in external memory.

The maximum number of collections that are supported is limited by the size of the ICID:

• If GITS_TYPER.CIL == 0, the ICID is 16 bits.

• If GITS_TYPER.CIL == 1, the ICID is reported by GITS_TYPER.CIDbits.

5.2.3 The Device table

The Device table provides a table of Device table entries (DTEs). Each DTE describes a mapping between a DeviceID and an ITT base address that points to the memory that the ITS can use to store the translations for the EventID. The ITS uses the ITT to store the translations for every EventID for the specified DeviceID. The DeviceID is a unique identifier assigned to each device that can create a range of EventIDs. For example, Arm expects that the 16-bit Requester ID from a PCIe Root Complex is presented to an ITS as a DeviceID.

The DeviceID provides the index value for the table. Table 5-2 shows an example of the number of bits that might be assigned to each DTE.

Table 5-2 DTE entries

5.2.4 The Interrupt translation table

An Interrupt translation table (ITT) is specific to each device that can create numbered events. Each entry in an ITT is referred to as an Interrupt translation entries (ITEs).

In GICv3, ITEs are only defined for physical interrupts.

In GICv4, ITEs are defined for physical interrupts and for virtual interrupts, and provide a distinction between:

• An entry for a physical LPI and the use of an ICT for routing information.

• An entry for a virtual LPI and the use of a vPE table .

An ITT must be assigned a contiguous physical address space starting at ITT Address. The size is 2^(DTE.ITT Range + 1)* GITS_TYPER.ITT_entry_size.

Behavior is UNPREDICTABLE if the memory does not contain all zeros at the time of new allocation for use by the ITS.

If multiple ITTs overlap in memory, behavior is UNPREDICTABLE.

ITS accesses to an ITT use the same Shareability and Cacheability attributes that are specified for the Device table.

For physical interrupts, each ITE describes the mapping between the input EventID and:

• The output physical INTID (pINTID) that is sent to the target PE.

• The ICID that identifies an entry in the Collection table, that determines the target PE for the LPI. For more information about the Collection table, see The Collection table.

For virtual interrupts, each ITE describes the mapping of the EventID as outlined in the preceding list, and:

• The output virtual INTID (vINTID) that is sent to the target vPE.

• The virtual PE number (vPEID) that identifies an entry in the vPE table to determine the current host Redistributor. For more information about the vPE table, see The vPE table.

• A physical LPI that is sent to a physical PE if a virtual interrupt is translated when the target vPE is not currently scheduled on a physical PE.

The EventID provides the index value for the table.

Table 5-3 shows an example of the number of bits that might be stored in an ITE.

Table 5-3 ITE entries

a. For information about the size of the LPI number space, see INTIDs.

5.2.5 The Collection table

The Collection table (CT) provides a table of Collection table entries (CTEs). For physical LPIs only, each CTE describes a mapping between:

• The ICID generated by the ITT.

• The address of the target Redistributor in the format defined by GITS_TYPER.PTA.

There is a single CT for each ITS, which can be held in registers or in memory, or in a combination of the two. See GITS_BASER.Type and GITS_TYPER.HCC for more information.

The TableID provides the index value for the table. It is derived from ICID.

Table 5-4 shows an example of the number of bits that might be assigned to each CT.

Table 5-4 CT entries

5.2.6 The vPE table

The vPE table consists of vPE table entries that provide a mapping from the vPEID generated by the ITS to:

• The target Redistributor, in the format defined by GITS_TYPER.PTA.

• The base address of the virtual LPI Pending table associated with the target vPE.

An area of memory defined by GITS_BASER holds the vPE table and indicates the size of each entry in the table.

The vPE table describes all the vPEs associated with an ITS. Table 5-5 shows an example of the number of bits that an implementation might store in a vPE table. The 16-bit vPEID provides the index value for the table.

Table 5-5 vPE table entries

5.2.7 Control and configuration of the ITS

An ITS is controlled and configured using a memory-mapped interface where:

• The version can be read from GITS_IIDR and from GITS_PIDR2.

• GITS_TYPER specifies the features that are supported by an ITS.

• GITS_CTLR controls the operation of an ITS.

• GITS_TRANSLATER receives EventID information. It is IMPLEMENTATION DEFINED how the DeviceID is supplied. See ITS commands for more details.

• GITS_BASER registers provide information about the type, size and access attributes for the architected ITS memory structures.

• GITS_CBASER, GITS_CREADR, and GITS_CWRITER store address information for the ITS command queue interface.

There is an enable bit for each ITS, GITS_CTLR.Enabled.

5.2.8 The ITS command interface

Figure 5-5 shows how the ITS provides the base address and the size that are used by the ITS command queue.

GITS_CBASER, GITS_CREADR, and GITS_CWRITER define the ITS command queue.

• GITS_CBASER uses the following fields:

  • Valid. This field indicates the allocation of memory for the ITS command queue.

  • Cacheability. This field indicates the cacheability attributes of accesses to the ITS command queue.

  • Shareability. This field indicates the Shareability attributes of accesses to the ITS command queue.

  • Physical address. This field provides the base physical address of the memory containing the ITS command queue.

  • Size. This field indicates the number of 4KB pages of physical memory for the ITS command queue.

• GITS_CREADR specifies the base address offset from which an ITS reads the next command to execute.

• GITS_CWRITER specifies the base address offset of the next free entry to which software writes the next command.

The size of an ITS command queue entry is 32 bytes. This means that there is support for 128 entries in each 4KB page.

The ITS command queue uses a little endian memory order model.

In the ITS command queue:

• The base address is always aligned to 64KB.

• Size is expressed as a multiple of 4KB.

• The address at which the queue wraps is always aligned to 4KB, and is (base address + (Size * 4KB)).

Note

All addresses are Non-secure physical addresses. When the first command is complete, the ITS starts to process the next command. The read pointer, GITS_CREADR, advances as the ITS processes commands. If GITS_CREADR reaches the top of the memory specified in GITS_CBASER then the pointer wraps back to the base address specified in GITS_CBASER. GITS_CWRITER is controlled by software.

The ITS command queue is empty when GITS_CWRITER and GITS_CREADR specify the same base address offset value.

The ITS command queue is full when GITS_CWRITER points to an address 32 bytes behind GITS_CREADR in the buffer.

When GITS_CREADR.Stalled == 1 no subsequent commands are processed.

The INT ITS command generates an interrupt on execution, and this can generate an interrupt on completion of a particular sequence of commands, see ITS commands.

5.2.9 Ordering of translations with the output to ITS commands

Each command queue entry appears to be executed atomically so that a translation request either sees the state of the ITS before a command or the state of the ITS after the command.

A translation request initiated after a SYNC or VSYNC command has completed is translated using an ITS state that is consistent with the state after the command is performed.

In the absence of a SYNC or VSYNC command the ordering of ITS commands and translation requests is not defined by the architecture.

5.2.10 Restrictions for INTID mapping rules

The behavior of the GIC is unpredictable if software:

• Maps multiple EventID-DeviceID combinations to the same physical LPI INTID.

• Assigns doorbell interrupts with the same physical LPI INTID to different physical PEs. This applies to GICv4 only.

• Maps an EventID-DeviceID combination and an individual doorbell interrupt to the same physical LPI INTID, unless they target the same physical PE. This applies to all versions of GICv4.

• Maps multiple EventID-DeviceID combinations to the same virtual LPI INTID-vPEID. This applies to GICv4 only.

• Maps an EventID-DeviceID combination and a default doorbell interrupt to the same physical LPI INTID. This applies to GICv4.1 only.

• Maps a default doorbell and an individual doorbell to the same physical LPI INTID. This applies to GICv4.1 only.

Note Conceptually the restriction is that software should not map multiple EventID-DeviceID combinations to the same vLPI within a given virtual machine. However, the ITS has no awareness of which vPEs belong to the same virtual machine.

5.3 ITS commands

Table 5-6 provides a summary of all ITS commands.

Table 5-6 ITS commands

Arm IHI 0069G Table 5-6 ITS commands (continued)

• a. This command was previously called MAPVI.

• b. This command exists in GICv4 only.

• c. This command was previously called VMAPVI.

The number of bits of EventID and DeviceID that an implementation supports are discoverable from GITS_TYPER. Unimplemented bits are RES0.

Note

• The INTID of an LPI is in the range of 8192 - maximum number. The maximum number is IMPLEMENTATION DEFINED. See INTIDs.

• The following argument names have been changed from those used in preliminary information associated with this GIC specification:

  • Device has been changed to DeviceID.

  • ID has been changed to EventID.

  • pID has been changed to pINTID.

  • vID has been changed to vINTID.

  • pCID has been changed to ICID.

  • target address has been changed to RDbase.

  • VCPU has been changed to vPE.

• The format of the collection target address, RDbase, is indicated by GITS_TYPER.PTA.

5.3.1 IMPLEMENTATION DEFINED sizes in ITS command parameters

Some ITS commands include the following types of parameter that have an IMPLEMENTATION DEFINED size:

DeviceIDs

The maximum number of Device identifiers supported by the associated Device table is determined by the number of bits available, as specified by GITS_TYPER.Devbits.

EventID EventID is limited by the maximum MAPD Size field, which is limited by GITS_TYPER.ID_bits. ICID The number of collections supported is IMPLEMENTATION DEFINED:

• For implementations that do not support Collection tables in external memory, GITS_TYPER.HCC indicates the number of collections.

• For implementations that do support Collection tables in external memory, the number of supported collections is limited by the size of the allocated collection table: — The total number of collections supported is calculated as follows: GITS_TYPER.HCC + (Size of collection table / Entry size) When GITS_TYPER.CIL == 1, the maximum number of collections is limited by GITS_TYPER.CIDbits. pINTID pINTID is limited by GICR_PROPBASER.IDbits, which is limited by GICD_TYPER.IDbits. This also applies to Dbell_pINTID.

RDbase

RDbase is associated with a Redistributor and is specified in one of two formats:

• The base physical address of RD_base when GITS_TYPER.PTA == 1.

Note Addresses can be up to 52 bits in size and must be 64KB aligned. The RDbase field consists of bits[51:16] of the address.

• A PE number, as indicated in GICR_TYPER.Processor_Number when GITS_TYPER.PTA == 0.

• vINTID vINTID can be limited by GICR_VPROPBASER.IDbits, which is limited by GICD_TYPER.IDbits.

vPEID vPEID is limited by the size of the vPE table.

5.3.2 Command errors

If the ITS detects an error in the data provided to a command, the resulting behavior is a CONSTRAINED UNPREDICTABLE choice of:

• Ignoring the command:

  • No action is performed that alters the handling of interrupts.

  • GITS_CREADR is incremented to point to the next command, wrapping if necessary.

  • If GITS_TYPER.SEIS is set to 1, a System error is generated.

Note

It is IMPLEMENTATION DEFINED how the System error is recorded and how it is reported to the PE.

• Stalling the ITS command queue:

  • GITS_CREADR is not incremented and continues to point to the entry that triggered the error.

  • — GITS_CREADR.Stalled is set to 1.

  • Software can restart the processing of commands by writing 1 to GITS_CWRITER.Retry.

  • If GITS_TYPER.SEIS is set to 1, a System error is generated.

    • Note

It is IMPLEMENTATION DEFINED how the system error is recorded and how it is reported to the PE.

• Treating the data as valid data:

  • The data that generated the error or errors is treated as having a legal value, and the command is processed accordingly.

  • GITS_CREADR is incremented to point to the next command, wrapping if necessary.

  • If GITS_TYPER.SEIS is set to 1 a System error is generated.

Note

It is IMPLEMENTATION DEFINED how the System error is recorded and how it is reported to the PE.

See ITS command error encodings for more information.

5.3.3 CLEAR

This command translates the event defined by EventID and DeviceID into an ICID and pINTID, and instructs the appropriate Redistributor to remove the pending state.

Figure 5-6 shows the format of the CLEAR command.

Figure 5-6 CLEAR command format

In Figure 5-6:

• EventID identifies the interrupt, associated with a device, for which the pending state is to be cleared.

• DeviceID specifies the requesting device.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

CLEAR DeviceID, EventID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an Interrupt translation table, using MAPD.

• EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• The EventID for the device is not mapped to a collection, using MAPI or MAPTI.

• The EventID for the device is mapped to a collection that has not been mapped to an RDbase using MAPC.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the CLEAR command:

// ITS.CLEAR // =========

ITS.CLEAR(ITSCommand cmd)
    if DeviceOutOfRange(cmd.DeviceID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError CLEAR_DEVICE_OOR";
UNPREDICTABLE;

dte = ReadDeviceTable(UInt(cmd.DeviceID));

if !dte.Valid then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError CLEAR_UNMAPPED_DEVICE";
        UNPREDICTABLE;
    if IdOutOfRange(cmd.EventID, dte.ITT_size) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError CLEAR_ID_OOR";
            UNPREDICTABLE;
        InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
        if !ite.Valid then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError CLEAR_UNMAPPED_INTERRUPT";
                UNPREDICTABLE;
            success = ClearPendingState(ite);
            if !success then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError CLEAR_ITE_INVALID";
                    UNPREDICTABLE;
                IncrementReadPointer();
                return;

5.3.4 DISCARD

This command translates the event defined by EventID and DeviceID and instructs the appropriate Redistributor to remove the pending state of the interrupt. It also ensures that any caching in the Redistributors associated with a specific EventID is consistent with the configuration held in memory. DISCARD removes the mapping of the DeviceID and EventID from the ITT, and ensures that incoming requests with a particular EventID are silently discarded.

Figure 5-7 shows the format of the DISCARD command.

Figure 5-7 DISCARD command format

In Figure 5-7:

• EventID identifies the interrupt, associated with a device, that is to be discarded.

• DeviceID specifies the requesting device.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

DISCARD DeviceID, EventID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• The EventID for the device is not mapped to a collection, using MAPI or MAPTI.

• The EventID for the device is mapped to a collection that has not been mapped to an RDbase using MAPC.

In this case, the ITS must take the actions described in Command errors.

In GICv4.1, when this command is issued for an EventID and DeviceID that maps to a virtual LPI, and the associated vPEID is not mapped to a Redistributor on that ITS:

• It removes the mapping for the EventID and DeviceID on the ITS.

• If the vPE is mapped on at least one other ITS, it is IMPLEMENTATION DEFINED whether the pending state is cleared.

• If the vPE is not mapped on any ITS, the pending state is not cleared.

A vPEID is classed as not mapped if no VMAPP with V=1 has been issued for it, or if it has been unmapped by a VMAPP with V=0.

The following pseudocode describes the operation of the DISCARD command:

// ITS.DISCARD // ===========

ITS.DISCARD(ITSCommand cmd)
    if DeviceOutOfRange(cmd.DeviceID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError DISCARD_DEVICE_OOR";
UNPREDICTABLE;

DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));

if !dte.Valid then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError DISCARD_UNMAPPED_DEVICE";
        UNPREDICTABLE;
    if IdOutOfRange(cmd.EventID, dte.ITT_size) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError DISCARD_ID_OOR";
            UNPREDICTABLE;
        InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
        if ite.Valid then success = ClearPendingState(ite);
        if !success then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError DISCARD_ITE_INVALID";
                UNPREDICTABLE;
        else if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError DISCARD_UNMAPPED_INTERRUPT";
            UNPREDICTABLE;

ite.Valid = FALSE; WriteTranslationTable(dte.ITT_base, UInt(cmd.EventID), ite);

IncrementReadPointer(); return;

5.3.5 INT

This command translates the event defined by EventID and DeviceID into an ICID and pINTID, and instructs the appropriate Redistributor to set the interrupt pending.

Figure 5-8 shows the format of the INT command.

Figure 5-8 INT command format In Figure 5-8:

• EventID identifies an interrupt source associated with a device. The ITS then translates this into an LPI INTID.

• DeviceID specifies the requesting device.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

INT DeviceID, EventID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• EventID is not mapped to a collection, using MAPI or MAPTI.

• The EventID for the device is mapped to a collection that has not been mapped to an RDbase using MAPC.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the INT command:

// ITS.INT // ======= ITS.INT(ITSCommand cmd)
if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError INT_DEVICE_OOR";
        UNPREDICTABLE;
    DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
    if !dte.Valid then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError INT_UNMAPPED_DEVICE";
            UNPREDICTABLE;
        if IdOutOfRange(cmd.EventID, dte.ITT_size) then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError INT_ID_OOR";
                UNPREDICTABLE;
            InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
            if !ite.Valid then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError INT_UNMAPPED_INTERRUPT";
                    UNPREDICTABLE;
                boolean success = SetPendingState(ite);
                if !success then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError INT_ITE_INVALID";
                        UNPREDICTABLE;
                    IncrementReadPointer();
                    return;

5.3.6 INV

This command specifies that the ITS must ensure that any caching in the Redistributors associated with the specified EventID is consistent with the LPI Configuration tables held in memory.

In GICv4.1, it is IMPLEMENTATION DEFINED whether INV affects the generation and prioritization of default doorbells.

Note The INV command performs the same function regardless of whether the interrupt is mapped as a physical interrupt or a virtual interrupt.

Figure 5-9 shows the format of the INV command.

Figure 5-9 INV command format

In Figure 5-9:

• EventID identifies an interrupt source associated with a device. The ITS then translates this into an LPI INTID.

• DeviceID specifies the requesting device.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet. The command and its arguments are:

INV DeviceID, EventID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• EventID is not mapped to a collection, using MAPI or MAPTI.

• The EventID for the device corresponds to a physical LPI and is mapped to a collection that has not been mapped to an RDbase using MAPC.

• The EventID for the device corresponds to a virtual LPI associated with a vPE that has not been mapped to a Redistributor using VMAPP GICv4.0 or VMAPP GICv4.1.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the INV command:

// ITS.INV // ======= ITS.INV(ITSCommand cmd)
if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError INV_DEVICE_OOR";
        UNPREDICTABLE;
    DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
    if !dte.Valid then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError INV_UNMAPPED_DEVICE";
            UNPREDICTABLE;
        if IdOutOfRange(cmd.EventID, dte.ITT_size) then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError INV_ID_OOR";
                UNPREDICTABLE;
            InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
            if !ite.Valid then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError INV_UNMAPPED_INTERRUPT";
                    UNPREDICTABLE;
                invalidateByITE(ite);
                IncrementReadPointer();
                return;

5.3.7 INVALL

This command specifies that the ITS must ensure any caching associated with the interrupt collection defined by ICID is consistent with the LPI Configuration tables held in memory for all Redistributors.

In GICv4.1, it is IMPLEMENTATION DEFINED whether INVALL affects the generation and prioritization of default doorbells.

Figure 5-10 shows the format of the INVALL command.

In Figure 5-10:

• ICID specifies the interrupt collection.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

INVALL ICID

A command error occurs if any of the following apply:

• The collection specified by ICID exceeds the maximum number supported by the ITS.

• The collection specified by ICID has not been mapped to an RDbase using MAPC.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the INVALL command:

// ITS.INVALL // ==========

ITS.INVALL(ITSCommand cmd)
    if (CollectionOutOfRange(cmd.ICID))
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError INVALL_COLLECTION_OOR";
UNPREDICTABLE;

CollectionTableEntry cte = ReadCollectionTable(UInt(cmd.ICID));

if !cte.Valid then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError INVALL_UNMAPPED_COLLECTION";
        UNPREDICTABLE;
    // This invalidates any caches containing the configuration data
    for all interrupts in the
    // collection. Over invalidation is permitted.
    InvalidateCollectionCaches(UInt(cmd.ICID));
    IncrementReadPointer();
    return;

5.3.8 INVDB GICv4.1 only

In GICv4.1, the ITS command INVDB is allocated to invalidate the configuration of default doorbells:

Figure 5-11 shows the format of the INVDB command for GICv4.1 only.

• vPEID = The vPEID of the vPE.

// ITS.INVDB // ========= ITS.INVDB(ITSCommand cmd)
if VCPUOutOfRange(cmd.VCPUID) then
    if GITS_TYPER.SEIS == 1 then
        IMPLEMENTATION_DEFINED "SError INVDB_VCPU_OOR";
        UNPREDICTABLE;
    VCPUTableEntry vte = ReadVCPUTable(UInt(cmd.VCPUID));
    if vte.Valid then InvalidateInterruptDoorbellCaches(VCPUID, vte);
    IncrementReadPointer();
    return;

INVDB is synchronized by a VSYNC command.

After completion of an INVDB command, there is no caching associated with the default doorbell of the specified vPE in any Redistributor.

A command error occurs if any of the following apply:

• An INVDB is issued with a vPEID that exceeds the configured maximum vPEID for the ITS: INVDB_VCPU_OOR (0x01_2E11).

An INVDB with a valid vPEID behaves as a NOP if either of the following points is true:

• The vPEID is not mapped on the ITS.

• The vPEID has no default doorbell.

5.3.9 MAPC

This command maps the Collection table entry defined by ICID to the target Redistributor, defined by RDbase.

Figure 5-12 shows the format of the MAPC command.

Figure 5-12 MAPC command format

In Figure 5-12:

• V specifies whether RDbase is valid for the collection.

• RDbase specifies the target Redistributor to which interrupts in the collection are forwarded. See IMPLEMENTATION DEFINED sizes in ITS command parameters.

• ICID specifies the interrupt collection that is to be mapped.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

If GITS_TYPER.PTA == 1 and a physical address is specified, the target addresses must be 64KB aligned, meaning that only bits[47:16] are required. See IMPLEMENTATION DEFINED sizes in ITS command parameters for more information. In addition, when V is cleared to 0, this field must be written as zero, but hardware might ignore the value.

The command and its arguments are: MAPC ICID, RDbase, V

When V is 1:

• Behavior is unpredictable if there are interrupts that are mapped to the specified collection and the collection is currently mapped to a Redistributor, unless MAPC is followed by MOVALL so that the pending state for the collection is moved from the old target Redistributor or the new target Redistributor. MOVALL might be issued by a different ITS:

  • Where multiple collections are remapped from the same source to the same destination, behavior is unpredictable if MOVALL is issued before all the MAPCs are globally observable.

  • Behavior is unpredictable if any ITS command that affects interrupts that belong to a remapped collection is issued after the MAPC, but before the MOVALL is globally observable.

• Behavior is unpredictable if RDbase does not specify a valid Redistributor.

When V is 0:

• MAPC removes the mapping of the specified interrupt collection. Interrupts for that are mapped to this collection are ignored.

• Behavior is unpredictable if there are interrupts that are mapped to the specified collection, with the restriction that further translation requests from that device are ignored.

A command error occurs if the following applies:

• The collection specified by ICID exceeds the maximum number supported by the ITS.

In this case, the ITS must take the actions described in Command errors.

Note

When software uses a MAPC command to move a collection from targeting Redistributor A to targeting Redistributor B, it must issue a SYNC command to Redistributor A before issuing the accompanying MOVALL command. Otherwise, interrupts from the collection might still be taken by the PE associated with Redistributor A.

The following pseudocode describes the operation of the MAPC command:

// ITS.MAPC // ======== ITS.MAPC(ITSCommand cmd)
if CollectionOutOfRange(cmd.ICID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError MAPC_COLLECTION_OOR";
        UNPREDICTABLE;
    CollectionTableEntry cte;
    cte.Valid  = cmd.V == '1';
    cte.RDbase = cmd.RDbase;
    WriteCollectionTable(UInt(cmd.ICID), cte);
    IncrementReadPointer();
    return;

5.3.10 MAPD

This command maps the Device table entry associated with DeviceID to its associated ITT, defined by ITT_addr and Size.

Figure 5-13 shows the format of the MAPD command.

Figure 5-13 MAPD command format In Figure 5-13:

• DeviceID specifies the device that uses the ITT.

Note For more information about mapping devices to ITTs, see The Interrupt translation table.

• V specifies whether the ITT_addr and Size fields are valid.

• ITT_addr specifies bits[51:8] of the physical address of the ITT.

• Size is a 5-bit number that specifies the supported number of bits for the device, minus one. The size field enables range checking of EventID for translation requests for this DeviceID.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

Behavior is UNPREDICTABLE if any of the following apply:

• There is an existing mapping for the DeviceID and the mapped ITT contains valid EventID mappings.

• When V == 1, the specified ITT does not contain all zeros.

The command and its arguments are:

MAPD DeviceID, ITT_addr, Size, V

The format of the ITT entries is IMPLEMENTATION DEFINED. A typical example entry size of 8 bytes permits allocation of identifiers to devices in multiples of 32 interrupts.

When V is 1:

• MAPD associates a DeviceID with a 256 byte-aligned address of an ITT.

• When V is 0:

• MAPD removes the mapping for the specified DeviceID. Translation requests from that device are ignored.

• MAPD removes the mapping of the specified DeviceID. and interrupt requests from that device are discarded. A subsequent translation for the DeviceID does not generate and LPI or VLPI until DeviceID has been mapped to the ITT again.

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum number of devices supported by an ITS.

• Size exceeds the maximum value permitted by the settings of GITS_TYPER.ID_bits, when V is set to 1.

In this case, the ITS must take the actions described in Command errors.

Note ITS accesses to an ITT use the same Shareability and Cacheability attributes that are specified for the Device table, see The Device table.

The following pseudocode describes the operation of the MAPD command:

// ITS.MAPD // ======== ITS.MAPD(ITSCommand cmd)
    if DeviceOutOfRange(cmd.DeviceID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError MAPD_DEVICE_OOR";
UNPREDICTABLE;
if SizeOutOfRange(cmd.Size) then

if GITS_TYPER.SEIS == '1' then IMPLEMENTATION_DEFINED "SError MAPD_ITTSIZE_OOR"; UNPREDICTABLE;
// If a device is Re-mapped software must perform the following actions
// to ensure the LPI configuration is up to date:
// 1. Ensure that the device is quiescent and that all interrupts have
//     been handled.
// 2. Remap the device with the new (empty) ITT
//
DeviceTableEntry dte;

5.3.11 MAPI

This command maps the event defined by EventID and DeviceID into an ITT entry with ICID and pINTID = EventID.

Note

• pINTID ≥0x2000 for a valid LPI INTID.

• This is equivalent to MAPTI DeviceID, EventID, EventID, ICID

Figure 5-14 shows the format of the MAPI command.

Figure 5-14 MAPI command format

In Figure 5-14:

• EventID identifies the interrupt, associated with a device, that is to be mapped.

• DeviceID specifies the requesting device.

• ICID specifies the interrupt collection that includes the specified interrupt.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

If there is an existing mapping for the EventID-DeviceID combination, behavior is UNPREDICTABLE.

The command and its arguments are:

MAPI DeviceID, EventID, ICID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• ICID exceeds the maximum number of interrupt collections supported by an ITS. For more information, see The Collection table.

• The EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued. • EventID does not specify a valid LPI identifier. See INTIDs. In this case, the ITS must take the actions described in Command errors. The following pseudocode describes the operation of the MAPI command:

// ITS.MAPI // ======== ITS.MAPI(ITSCommand cmd)
if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError MAPI_DEVICE_OOR";
        UNPREDICTABLE;
    if CollectionOutOfRange(cmd.ICID) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError MAPI_COLLECTION_OOR";
            UNPREDICTABLE;
        DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
        if !dte.Valid then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError MAPI_UNMAPPED_DEVICE";
                UNPREDICTABLE;
            if IdOutOfRange(cmd.EventID, dte.ITT_size) then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError MAPI_ID_OOR";
                    UNPREDICTABLE;
                if LPIOutOfRange(cmd.EventID) then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError MAPI_ID_OOR";
                        UNPREDICTABLE;
                    InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));

ite.Valid = TRUE; ite.Type = physical_interrupt; ite.OutputID = cmd.EventID; ite.DoorbellID = ZeroExtend(INTID_SPURIOUS); // Don’t generate a doorbell ite.ICID = cmd.ICID;

WriteTranslationTable(dte.ITT_base, UInt(cmd.EventID), ite);

IncrementReadPointer();

return;

5.3.12 MAPTI

This command maps the event defined by EventID and DeviceID to its associated ITE, defined by ICID and pINTID in the ITT associated with DeviceID.

Figure 5-15 shows the format of the MAPTI command.

Figure 5-15 MAPTI command format In Figure 5-15:

• EventID identifies the interrupt, associated with a device, that is to be mapped.

• pINTID is the INTID of the physical interrupt that is presented to software.

• DeviceID specifies the requesting device.

• ICID specifies the interrupt collection that includes the specified physical interrupt.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

If there is an existing mapping for the EventID-DeviceID combination, behavior is UNPREDICTABLE.

The command and its arguments are:

MAPTI DeviceID, EventID, pINTID, ICID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT using MAPD.

• The number of collections exceeds the maximum number of collections supported by the ITS. For more information, see The Collection table.

• The EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• pINTID does not specify a valid LPI INTID. For information about the LPI INTID range, see INTIDs.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the MAPTI command:

// ITS.MAPTI // =========

ITS.MAPTI(ITSCommand cmd)

if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError MAPTI_DEVICE_OOR";
        UNPREDICTABLE;
    if CollectionOutOfRange(cmd.ICID) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError MAPTI_COLLECTION_OOR";
            UNPREDICTABLE;
        DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
        if !dte.Valid then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError MAPTI_UNMAPPED_DEVICE";
                UNPREDICTABLE;
            if IdOutOfRange(cmd.EventID, dte.ITT_size) then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError MAPTI_ID_OOR";
                    UNPREDICTABLE;
                if LPIOutOfRange(cmd.pINTID) then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError MAPTI_PHYSICALID_OOR";
                        UNPREDICTABLE;
                    InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));

ite.Valid = TRUE; ite.Type = physical_interrupt; ite.OutputID = cmd.pINTID; ite.DoorbellID = ZeroExtend(INTID_SPURIOUS); // Don’t generate a doorbell ite.ICID = cmd.ICID;

WriteTranslationTable(dte.ITT_base, UInt(cmd.EventID), ite);

IncrementReadPointer();

return;

5.3.13 MOVALL

This command instructs the Redistributor specified by RDbase1 to move all of its interrupts to the Redistributor specified by RDbase2.

Note Both the mapping of interrupts to collections and the mapping of collections to Redistributors are normally unaffected by this command. Software must ensure that any interrupts that might be affected by this command target the Redistributor specified by RDbase2, otherwise system behavior is UNPREDICTABLE. In particular, an implementation might choose to remap all affected collections to RDbase2.

Figure 5-16 shows the format of the MOVALL command.

Figure 5-16 MOVALL command format

In Figure 5-16:

• RDbase1 specifies the Redistributor with which the interrupts are currently associated. See IMPLEMENTATION DEFINED sizes in ITS command parameters.

• RDbase2 specifies the Redistributor to which the interrupts are to be moved. See IMPLEMENTATION DEFINED sizes in ITS command parameters.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

MOVALL RDbase1, RDbase2

Behavior is unpredictable if RDbase1 and RDbase2 do not specify a valid Redistributor. The format of these fields is specified by GITS_TYPER.PTA.

MOVALL targeting a RD with LPIs disabled is CONSTRAINED UNPREDICTABLE, with a choice of:

• Clear the pending state of all moved LPIs.

• Act as NOP, with the pending state is unchanged on the source RD.

The following pseudocode describes the operation of the MOVALL command:

// ITS.MOVALL // ==========

ITS.MOVALL(ITSCommand cmd) rd1 = cmd.RD1base;
rd2 = cmd.RD2base;
if rd1 != rd2
    then MoveAllPendingState(rd1, rd2);

IncrementReadPointer();

return;

5.3.14 MOVI

This command updates the ICID field in the ITT entry for the event defined by DeviceID and EventID. It also translates the event defined by EventID and DeviceID into an ICID and pINTID, and instructs the appropriate Redistributor to move the pending state, if it is set, of the interrupt to the Redistributor defined by the new ICID, and to update the ITE associated with the event to use the new ICID.

Figure 5-17 shows the format of the MOVI command.

Figure 5-17 MOVI command format

In Figure 5-17:

• EventID identifies the interrupt, associated with a device, that is to be redirected.

• DeviceID specifies the requesting device.

• ICID specifies the new interrupt collection that is to include the specified physical interrupt.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

MOVI DeviceID, EventID, ICID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• ICID exceeds the maximum number of interrupt collections supported by an ITS.

• ICID is not mapped to an RDbase using MAPC.

• EventID is not mapped to a collection, using MAPI or MAPTI.

• EventID corresponds to a virtual LPI.

In this case, the ITS must take the actions described in Command errors.

Note If, after using MOVI to move an interrupt from collection A to collection B, software moves the same interrupt again from collection B to collection C, a SYNC command must be used before the second MOVI for the Redistributor associated with collection A to ensure correct behavior.

When MOVI is issued targeting a Collection that is unmapped, or mapped to a Redistributor with LPIs disabled, behavior is CONSTRAINED UNPREDICTABLE, with a choice of:

• Clear the pending state of the moved LPI.

• Pending state unchanged on the source RD.

The following pseudocode describes the operation of the MOVI command:

// ITS.MOVI // ========

ITS.MOVI(ITSCommand cmd)

if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError MOVI_DEVICE_OOR";
        UNPREDICTABLE;
    if CollectionOutOfRange(cmd.ICID) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError MOVI_COLLECTION_OOR";
            UNPREDICTABLE;
        DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
        if !dte.Valid then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError MOVI_UNMAPPED_DEVICE";
                UNPREDICTABLE;
            if IdOutOfRange(cmd.EventID, dte.ITT_size) then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError MOVI_ID_OOR";
                    UNPREDICTABLE;
                InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
                if !ite.Valid then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError MOVI_UNMAPPED_INTERRUPT";
                        IncrementReadPointer();
                        return;
                    if ite.Type == virtual_interrupt then
                        if GITS_TYPER.SEIS == '1' then
                            IMPLEMENTATION_DEFINED "SError MOVI_ID_IS_VIRTUAL";
                            UNPREDICTABLE;
                        CollectionTableEntry cte1 = ReadCollectionTable(UInt(ite.ICID));
                        if !cte1.Valid then
                            if GITS_TYPER.SEIS == '1' then
                                IMPLEMENTATION_DEFINED "SError MOVI_UNMAPPED_COLLECTION";
                                UNPREDICTABLE;
                            CollectionTableEntry cte2 = ReadCollectionTable(UInt(cmd.ICID));
                            if !cte2.Valid then
                                if GITS_TYPER.SEIS == '1' then
                                    IMPLEMENTATION_DEFINED "SError MOVI_UNMAPPED_COLLECTION";
                                    IncrementReadPointer();
                                    return;
                                bits(32) rd1 = cte1.RDbase;
                                bits(32) rd2 = cte2.RDbase;
                                if rd1 != rd2 then
                                    // Move the move the pending state to rd2
                                    if set taking care of any races where the
                                    // interrupt has been forwarded to the processor
                                    MovePendingState(rd1, rd2, ite.OutputID);

5.3.15 SYNC

This command ensures all outstanding ITS operations associated with physical interrupts for the Redistributor specified by RDbase are globally observed before any further ITS commands are executed. Following the execution of a SYNC, the effects of all previous commands must apply to subsequent writes to GITS_TRANSLATER.

Figure 5-18 shows the format of the SYNC command.

Figure 5-18 SYNC command format In Figure 5-18:

• RDbase specifies the physical address of the target Redistributor. The format of the target address is determined by GITS_TYPER.PTA. See IMPLEMENTATION DEFINED sizes in ITS command parameters for more information.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

SYNC RDbase

The following pseudocode describes the operation of the SYNC command:

// Wait for the external effects of any virtual commands to be observable by all redistributors
// and ensure the internal effects of any previous commands affect any subsequent interrupt
// requests or commands
WaitForVirtualCompletion(rd_base);

IncrementReadPointer();

return;

5.3.16 VINVALL

This command ensures that any cached Redistributor information associated with vPEID is consistent with the associated LPI Configuration tables held in memory.

This command is provided only in GICv4.

Figure 5-19 shows the format of the VINVALL command.

Figure 5-19 VINVALL command format

In Figure 5-19:

• vPEID specifies the vPE.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

VINVALL vPEID

A command error occurs if any of the following apply:

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• The PE specified by vPEID is not mapped to a Redistributor using VMAPP GICv4.0.

In this case, the ITS must take the actions described in Command errors. The following pseudocode describes the operation of the VINVALL command:

// ITS.VINVALL // ===========

ITS.VINVALL(ITSCommand cmd)
    if VCPUOutOfRange(cmd.VCPUID) then

if GITS_TYPER.SEIS == '1' then
    IMPLEMENTATION_DEFINED "SError VINVALL_VCPU_OOR";
    UNPREDICTABLE;
VCPUTableEntry vte = ReadVCPUTable(UInt(cmd.VCPUID));
if !vte.Valid then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError VINVALL_VCPU_INVALID";
        UNPREDICTABLE;
    InvalidateVCPUCaches(UInt(cmd.VCPUID));
    IncrementReadPointer();
    return;

5.3.17 VMAPI

This command maps the event defined by DeviceID and EventID into an ITT entry with vPEID, vINTID=EventID, and Dbell_PINTID, a doorbell provision.

Note

• vINTID ≥0x2000 for a valid LPI INTID.

• This is equivalent to VMAPTI DeviceID, EventID, EventID, pINTID, vPEID.

• Dbell_pINTID must be either 1023 or Dbell_pINTID ≥0x2000 for a valid LPI INTID.

This command is provided only in GICv4.

Figure 5-20 shows the format of the VMAPI command.

In Figure 5-20:

• EventID identifies the interrupt, associated with a device, that is to be presented to the VM.

• DeviceID specifies the requesting device.

• vPEID specifies the vPE.

• Dbell_pINTID specifies the ID that is presented to the hypervisor if the vPE is not scheduled.

  • Note

If Dbell_pINTID indicates a spurious interrupt, then no physical interrupt is generated.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

If there is an existing mapping for the EventID-DeviceID combination, behavior is UNPREDICTABLE.

The command and its arguments are:

VMAPI DeviceID, EventID, Dbell_pINTID, vPEID A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• EventID does not specify a valid LPI INTID. For information about valid LPI INTIDs, see INTIDs.

• Dbell_pINTID does not specify a valid doorbell INTID, where a valid INTID is either: — 1023.

  • Within the supported range for LPIs.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the VMAPI command:

// ITS.VMAPI // =========

ITS.VMAPI(ITSCommand cmd)
    if DeviceOutOfRange(cmd.DeviceID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError VMAPI_DEVICE_OOR";
UNPREDICTABLE;

if VCPUOutOfRange(cmd.VCPUID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError VMAPI_VCPU_OOR";
        UNPREDICTABLE;
    DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
    if !dte.Valid then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError VMAPI_UNMAPPED_DEVICE";
            UNPREDICTABLE;
        if IdOutOfRange(cmd.EventID, dte.ITT_size) then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError VMAPI_ID_OOR";
                UNPREDICTABLE;
            if LPIOutOfRange(cmd.EventID) then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError VMAPI_ID_OOR";
                    UNPREDICTABLE;
                if LPIOutOfRange(cmd.Dbell_pINTID) then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError VMAPI_PHYSICALID_OOR";
                        UNPREDICTABLE;
                    InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));

ite.Valid = TRUE; ite.Type = virtual_interrupt; ite.OutputID = cmd.EventID; ite.DoorbellID = cmd.Dbell_pINTID; ite.VCPUID = cmd.VCPUID;

WriteTranslationTable(dte.ITT_base, UInt(cmd.EventID), ite);

IncrementReadPointer();

return;

5.3.18 VMAPP GICv4.0

This command maps the vPE table entry defined by vPEID to the target RDbase, including an associated virtual LPI Pending table (VPT_addr, VPT_size).

Figure 5-21 shows the format of the VMAPP command for GICv4.0.

Figure 5-21 VMAPP GICv4.0 command format In Figure 5-21:

• vPEID specifies the vPE.

• V specifies whether the RDbase and VPT_addr are valid for the vPE.

• RDbase specifies the target Redistributor that owns the vPE and to which the ITS directs commands for that PE. See IMPLEMENTATION DEFINED sizes in ITS command parameters.

• VPT_addr specifies bits [51:16] of the physical address of the virtual LPI Pending table for the vPE.

Note The target addresses must be 64KB aligned, meaning that only bits [51:16] are required. Bits [15:0] of the physical address are 0.

• VPT_size specifies the number of vINTID bits that the vPE supports, minus one.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

VMAPP vPEID, RDbase, VPT_addr, VPT_size, V

When V is 0:

• VMAPP removes the mapping for the specified vPE. Interrupts that are mapped to this vPE are discarded.

When V is 1:

• Behavior is UNPREDICTABLE if RDbase does not specify a valid Redistributor.

A command error occurs if any of the following apply:

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• Size exceeds the maximum value permitted by the settings of GITS_TYPER.ID_bits.

In this case, the ITS must take the actions described in Command errors.

Note If a system contains multiple ITSs, Arm strongly recommends that software does not issue a VMAPP when there is an outstanding VMOVP for the same vPEID on another ITS, as this could create a race condition.

The following pseudocode describes the operation of the VMAPP command:

// ITS.VMAPP // =========

ITS.VMAPP(ITSCommand cmd)
    if VCPUOutOfRange(cmd.VCPUID) then

if GITS_TYPER.SEIS == '1' then IMPLEMENTATION_DEFINED "SError VMAPP_VCPU_OOR"; UNPREDICTABLE;

VCPUTableEntry vte;
// Common to GICv4.0 and GICv4.1
vte.Valid = cmd.V == '1';
vte.RDbase = cmd.RDbase;

if HasGIC41Ext() then
    // GICv4.1

    if ((Uint(cmd.VPT_size) < 14) || ((Uint(GICD_TYPER.bits) > 23)) then
        if ConstrainUnpredictableBool() then
            (c, cmd.VPT_size) = ConstrainUnpredictableInteger(14, 24);
            assert (c == Constraint_UNKNOWN);

    // Record configuration in vPE Configuration Table,
    // held by Redistributors
    WriteVPEConfigurationTable(UInt(cmd.VCPUID), cmd.RDbase,
        cmd.VCONF_addr, cmd.VPT_addr,
        cmd.Default_Doorbell_pINTID, cmd.VPT_size,
        cmd.V, cmd.Alloc, cmd.PTZ);

    // The ITS could record the size of the VPT to detect out of range
    // INTIDs, or it could rely on the Redistributors doing this.
else
    // GICv4.0
    if SizeOutOfRange(cmd.VPT_size) then
        if GITS_TYPER.SEIS == '1' then IMPLEMENTATION_DEFINED "SError
            VMAPP_VPTSIZE_OOR";
        UNPREDICTABLE;
    vte.VPT_base = cmd.VPT_addr:Zeros(16);
    vte.VPT_size = cmd.VPT_size;

WriteVCPUTable(UInt(cmd.VCPUID), vte);

IncrementReadPointer();

return;

5.3.19 VMAPP GICv4.1

The VMAPP command is modified in GICv4.1 to allow the specifying of the LPI configuration of the vPE and pending table locations.

Figure 5-22 shows the format of the VMAPP command for GICv4.1.

In Figure 5-22:

• RDbase = Identifies the target Redistributor. RES0 when V==0.

• VCONF_addr = Bits [51:16] of the address of the vPE’s Virtual Configuration Table, bits [15:0] are 0. RES0 when V==0.

• VPT_addr = Bits [51:16] of the address of the vPE’s Virtual Pending Table, bits [15:0] are 0. RES0 when V==0.

• VPT_size = The number of bits of vINTID for the vPE. RES0 when V==0.

• Default_Doorbell_pINTID is the default doorbell for the vPE. RES0 when V==0.

• Alloc = Signifies whether this is the first map, or last unmap, for this vPEID.

• PTZ = Signifies whether VPT_addr points at zeroed memory, ignored when V!=1 or Alloc!=1.

The command and its arguments are:

VMAPP vPEID, RDbase, VPT_addr, VPT_size, V

When V is 0:

• VMAPP removes the mapping for the specified vPE.

When V is 1:

• Behavior is UNPREDICTABLE if RDbase does not specify a valid Redistributor.

A command error occurs if any of the following apply:

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• Size exceeds the maximum value permitted by the settings of GITS_TYPER.ID_bits.

• VMAPP with V==1 specifies a Default_Doorbell_pINTID value other than 1023 that is outside the implemented LPI range. The command error code reported is 0x01_2906 (VMAPP_PHYSICALID_OOR).

In this case, the ITS must take the actions described in Command errors.

Note If a system contains multiple ITSs, Arm strongly recommends that software does not issue a VMAPP when there is an outstanding VMOVP for the same vPEID on another ITS, as this could create a race condition.

For the pseudocode that describes the operation of this command, see VMAPP GICv4.0.

Use of of the V and Alloc fields

GICv4.1 introduces the vPE Configuration table, which is associated with the Redistributors that record the locations of the virtual LPI Configuration and Pending tables. This table is populated using the VMAPP command.

The Alloc field in a VMAPP command is used when vPEs are created or destroyed, to indicate when the vPE Configuration table entry should be updated.

A VMAPP with {V, Alloc}=={0, 1} cleans and invalidates any cached virtual Pending table and virtual Configuration table associated with the vPEID held in the GIC. Invalid use of the Alloc field can cause UNPREDICTABLE behavior, including continued access by the IRI.

For a VMAPP when V==1, VPT_size determines the size of the vINTID namespace, from which the size of the virtual Configuration and Pending tables are derived.

For a VMAPP with V==1, if VPT_size is greater than the supported INTID size, one of the following CONSTRAINED UNPREDICTABLE values are used:

• The specified value.

• An UNKNOWN value in range value.

A VMAPP with V==1, Default_Doorbell_pINTID==1023 indicates no default doorbell.

A VMAPP with V==1 that specifies one of the following values of Default_Doorbell_pINTID, causes UNPREDICTABLE behavior to occur:

• The value is used for valid EventID or DeviceID mappings.

• The value is for the default doorbell of an existing valid vPE.

A VMAPP with Alloc==0 indicates that there is an existing mapping on at least one ITS for the vPEID. If this is not true, the resulting behavior is UNPREDICTABLE. A VMAPP with {V, Alloc}=={1, 1} indicates that this is the first mapping of the vPEID, in any ITS. Setting {V, Alloc}=={1, 1} at any other time causes UNPREDICTABLE behavior.

A VMAPP with {V, Alloc}=={0, 1} indicates that this is the last mapping for the vPEID, in any ITS. Setting {V, Alloc}=={0, 1} at any other time causes UNPREDICTABLE behavior.

The virtual LPI Configuration table and virtual LPI Pending table are allocated to the IRI when VMAPP with {V, Alloc}=={1, 1} is issued, and remains allocated to the IRI until VMAPP with {V, Alloc}=={0, 1} is completed. Table 5-7 summarizes the effects of the V and Alloc field combinations.

Table 5-7 Effects of V and Alloc field combinations

Note UNPREDICTABLE behavior associated with the invalid use of Alloc can include the IRI continuing to read or write memory structures associated with the vPEID after release. Arm strongly recommends avoiding these cases.

A VMAPP with {V, Alloc}=={0, x} is self-synchronizing. This means the ITS command queue does not show the command as consumed until all of its effects are completed.

When multiple ITSs are implemented, issuing VMAPPs with V==1 for the same vPEID on different ITSs with different values of VCONF_addr, VPT_addr or VPT_size, causes UNPREDICTABLE behavior.

When multiple ITSs are implemented, issuing VMAPPs with {V, Alloc}=={1, 0} where Default_Doorbell_pINTID or RDbase does not match the currently configured value causes UNPREDICTABLE behavior.

When {V, Alloc}!={1, 1}, the PTZ bit is IGNORED.

When {V, Alloc, PTZ}=={1, 1, 0}:

• The IMPLEMENTATION DEFINED region of the specified virtual Pending table must contain all zeros or have been populated by a GIC of the same implementation. Otherwise the behavior is UNPREDICTABLE.

• The pending state and SGI configuration will be loaded by the IRI.

When {V, Alloc, PTZ}=={1, 1, 1}, the specified virtual Pending table must contain all zeros, otherwise the behavior is UNPREDICTABLE. This includes the SGI and IMPLEMENTATION DEFINED regions.

5.3.20 VMAPTI

This command maps the event defined by DeviceID and EventID into an ITT entry with vPEID and vINTID, and Dbell_pINTID, a doorbell provision.

Note

• vINTID ≥0x2000 for a valid LPI INTID.

• Dbell_pINTID must be either 1023 or Dbell_pINTID ≥0x2000 for a valid LPI INTID.

This command is provided only in GICv4.

Figure 5-23 shows the format of the VMAPTI command.

In Figure 5-23:

• vPEID specifies the vPE.

• DeviceID specifies a device owned by the vPE.

• vINTID specifies the INTID presented to the vPE that controls the device that DeviceID specifies.

• Dbell_pINTID specifies the pINTID that is presented to the PE if the vPE is not scheduled.

Note If Dbell_pINTID is 1023 then no physical interrupt is generated.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

If there is an existing mapping for the EventID-DeviceID combination, behavior is UNPREDICTABLE.

The command and its arguments are:

VMAPTI DeviceID, EventID, vINTID, Dbell_pINTID, vPEID

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• The EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• vINTID does not specify a valid LPI INTID, see INTIDs.

• Dbell_pINTID does not specify a valid doorbell INTID, where a valid INTID is either: — 1023.

  • Within the supported range for LPIs.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the VMAPTI command:

// ITS.VMAPTI // ==========

ITS.VMAPTI(ITSCommand cmd)
    if DeviceOutOfRange(cmd.DeviceID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError VMAPTI_DEVICE_OOR";
UNPREDICTABLE;

if VCPUOutOfRange(cmd.VCPUID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError VMAPTI_VCPU_OOR";
        UNPREDICTABLE;
    DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
    if !dte.Valid then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError VMAPTI_UNMAPPED_DEVICE";
            UNPREDICTABLE;
        if IdOutOfRange(cmd.EventID, dte.ITT_size) then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError VMAPTI_ID_OOR";
                UNPREDICTABLE;
            if LPIOutOfRange(cmd.vINTID) then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError VMAPTI_VIRTUALID_OOR";
                    IncrementReadPointer();
                    return;
                if LPIOutOfRange(cmd.pINTID) then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError VMAPTI_PHYSICALID_OOR";
                        UNPREDICTABLE;
                    InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));

ite.Valid = TRUE; ite.Type = virtual_interrupt; ite.OutputID = cmd.vINTID; ite.DoorbellID = cmd.Dbell_pINTID; ite.VCPUID = cmd.VCPUID;

WriteTranslationTable(dte.ITT_base, UInt(cmd.EventID), ite);

IncrementReadPointer();

return;

5.3.21 VMOVI

This command updates the vPEID field in the ITT entry for the event defined by DeviceID and EventID. It also translates the event defined by EventID and DeviceID into a vPEID and pINTID, and instructs the appropriate Redistributor to move the pending state of the interrupt to the Redistributor defined by the new vPEID, and updates the ITE associated with the event to use the new vPEID.

This command is provided only in GICv4.

Figure 5-24 shows the format of the VMOVI command.

Figure 5-24 VMOVI command format

In Figure 5-24:

• vPEID specifies the vPE.

• EventID identifies the interrupt, associated with a device and already mapped by the ITS, that is to be moved to a new target specified by vPEID.

• D specifies whether the Dbell_pINTID field is valid.

• DeviceID specifies the device that generates the interrupt.

• Dbell_pINTID specifies the ID that is presented to the hypervisor if the vPE is not scheduled.

Note

If Dbell_pINTID is 1023 then no physical interrupt is generated.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

VMOVI DeviceID, EventID, vPEID, [Dbell_pINTID]

A command error occurs if any of the following apply:

• DeviceID exceeds the maximum value supported by the ITS.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• The device specified by DeviceID is not mapped to an ITT, using MAPD.

• The EventID exceeds the maximum value allowed by the ITT. This value is specified by the Size field when the MAPD command is issued.

• The vPE is not mapped to a Redistributor, using VMAPP GICv4.0.

• EventID corresponds to a physical LPI.

• If D is 1 and pINTID does not specify a valid doorbell INTID, where a valid INTID is either: — 1023.

  • Within the supported range for LPIs.

In this case, the ITS must take the actions described in Command errors.

Note If, after using VMOVI to move an interrupt from vPE A to vPE B, software moves the same interrupt again, a VSYNC command must be issued to vPE A between the moves to ensure correct behavior.

When VMOVI is issued targeting a vPE that is unmapped, or mapped to a Redistributor with LPIs disabled, behavior is CONSTRAINED UNPREDICTABLE with a choice of:

• Clear the pending state of the moved LPI.

• Pending state unchanged on the source vPE.

The following pseudocode describes the operation of the VMOVI command:

// ITS.VMOVI

// =========

ITS.VMOVI(ITSCommand cmd)

if DeviceOutOfRange(cmd.DeviceID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError VMOVI_DEVICE_OOR";
        UNPREDICTABLE;
    if VCPUOutOfRange(cmd.VCPUID) then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError VMOVI_VCPU_OOR";
            UNPREDICTABLE;
        if ( cmd.V == '1' && LPIOutOfRange(cmd.pINTID) && cmd.pINTID != '1023') then
            if GITS_TYPER.SEIS == '1' then
                IMPLEMENTATION_DEFINED "SError VMOVI_PHYSICALID_OOR";
                UNPREDICTABLE;
            DeviceTableEntry dte = ReadDeviceTable(UInt(cmd.DeviceID));
            if !dte.Valid then
                if GITS_TYPER.SEIS == '1' then
                    IMPLEMENTATION_DEFINED "SError VMOVI_UNMAPPED_DEVICE";
                    UNPREDICTABLE;
                if IdOutOfRange(cmd.EventID, dte.ITT_size) then
                    if GITS_TYPER.SEIS == '1' then
                        IMPLEMENTATION_DEFINED "SError VMOVI_ID_OOR";
                        UNPREDICTABLE;
                    InterruptTableEntry ite = ReadTranslationTable(dte.ITT_base, UInt(cmd.EventID));
                    if !ite.Valid then
                        if GITS_TYPER.SEIS == '1' then
                            IMPLEMENTATION_DEFINED "SError VMOVI_UNMAPPED_INTERRUPT";
                            UNPREDICTABLE;
                        if ite.Type == physical_interrupt then
                            if GITS_TYPER.SEIS == '1' then
                                IMPLEMENTATION_DEFINED "SError VMOVI_ID_IS_PHYSICAL";
                                UNPREDICTABLE;
                            VCPUTableEntry vte1 = ReadVCPUTable(UInt(ite.VCPUID));
                            VCPUTableEntry vte2 = ReadVCPUTable(UInt(cmd.VCPUID));
                            if !vte1.Valid then
                                if GITS_TYPER.SEIS == '1' then
                                    IMPLEMENTATION_DEFINED "SError VMOVI_ITEVCPU_INVALID";
                                    UNPREDICTABLE;
                                if !vte2.Valid then
                                    if GITS_TYPER.SEIS == '1' then
                                        IMPLEMENTATION_DEFINED "SError VMOVI_CMDVCPU_INVALID";
                                        UNPREDICTABLE;
                                    bits(32) rd1 = vte1.RDbase;
                                    Address vpt1 = vte1.VPT_base;
                                    bits(32) rd2 = vte2.RDbase;
                                    Address vpt2 = vte2.VPT_base;

ite.VCPUID = cmd.VCPUID;

// From this point new interrupts sent to the new VCPU move the pending
// state to rd2 if set taking care of any races where the interrupt
// has been forwarded to the processor
MoveVirtualPendingState(rd1, vpt1, vpt2, ite.OutputID);

IncrementReadPointer();

return;

5.3.22 VMOVP GICv4.0

This command updates the vPE table entry defined by vPEID to the target RDbase. Software must use SequenceNumber and ITSList to synchronize the execution of VMOVP commands across more than one ITS.

This command is provided only in GICv4.

Software must ensure that this command is not executed with a vPEID that is scheduled on the target Redistributor, otherwise system behavior is UNPREDICTABLE.

Figure 5-25 shows the format of the VMOVP command.

In Figure 5-25:

• vPEID specifies the vPE.

• RDbase specifies the Redistributor to which interrupts are forwarded. See IMPLEMENTATION DEFINED sizes in ITS command parameters.

• Sequence Number specifies the identity of the synchronization point that every ITS included in ITS List uses. When GITS_TYPER.VMOVP == 0 Sequence Number specifies the identity of the synchronization point that is used by all ITSs that are included in ITSList.

  • When GITS_TYPER.VMOVP == 1 Sequence Number is RES0.

  • For more information, see VMOVP usage.

• ITSList specifies the ITS instances that are included in the synchronization operation, where:

  • Each bit in ITS List identifies an ITS where bit[n] corresponds to ITS n.

  • An ITS is included if the corresponding bit is set to 1. When GITS_TYPER.VMOVP == 0 ITSList specifies which ITSs are included in the synchronization operation. Each bit of ITSList corresponds to an ITS, for example bit[0] of ITSList corresponds to ITS 0, bit[1] to ITS 1.

When GITS_TYPER.VMOVP ==1 ITSList is res0.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

VMOVP, vPEID, RDbase, SequenceNumber, ITSList

A command error occurs if any of the following apply:

• If the PE specified by vPEID is not mapped to a Redistributor, using VMAPP GICv4.0.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the VMOVP command:

// ITS.VMOVP // ========= ITS.VMOVP(ITSCommand cmd)
if VCPUOutOfRange(cmd.VCPUID) then
    if GITS_TYPER.SEIS == '1' then
        IMPLEMENTATION_DEFINED "SError VMOVP_VCPU_OOR";
        UNPREDICTABLE;
    VCPUTableEntry vte = ReadVCPUTable(UInt(cmd.VCPUID));
    if !vte.Valid then
        if GITS_TYPER.SEIS == '1' then
            IMPLEMENTATION_DEFINED "SError VMOVP_VCPU_INVALID";
            UNPREDICTABLE;

vte.RDbase = cmd.RDbase;

if HasGIC41Ext() then UpdateVPEConfigurationTable(UInt(cmd.VCPUID), cmd.RDbase, cmd.Default_Doorbell_pINTID);

WriteVCPUTable(UInt(cmd.VCPUID), vte);

IncrementReadPointer();

return;

VMOVP usage

Where more than one ITS controls interrupts for the same vPE, moving this vPE must be coordinated between the different ITSs. This is controlled by software using one of the two approaches detailed here:

When GITS_TYPER.VMOVP == 0:

• The VMOVP command must be issued for each ITS that controls interrupts for the vPE that is being moved. Each of these commands must have a common sequence number. That sequence number cannot be used for other VMOVP commands until all commands that previously used that sequence number have been processed by all ITSs.

• The VMOVP command issued for each ITS contains a list of all the ITSs that are affected by moving the vPE. This is the ITS List.

• Each ITS must have the sequence numbers presented to it in the same order in that they are presented to the other ITSs. When GITS_TYPER.VMOVP == 1:

• The VMOVP command must be issued on only one of the ITSs that controls interrupts for the vPE that is being moved.

• The implementation is responsible for propagating the updated mapping.

Not following this approach results in UNPREDICTABLE behavior.

Note If a system contains multiple ITSs, Arm strongly recommends that software does not issue a VMAPP when there is an outstanding VMOVP for the same vPEID on another ITS, as this could create a race condition.

5.3.23 VMOVP GICv4.1

The VMOVP command is modified in GICv4.1 to allow a Default Doorbell to be assigned to the vPE.

In Figure 5-26:

• Default_Doorbell_pINTID is the default doorbell for the vPE.

• DB signifies whether to mark the vPE as requiring a Default Doorbell on the target.

A VMOVP, Default_Doorbell_pINTID==1023 means no default doorbell. For a VMOVP with a valid Default_Doorbell_pINTID, other than 1023, the pending state of the default doorbell is transferred to the new target.

A VMOVP with Default_Doorbell_pINTID==1023 clears the pending state of the default doorbell on the old target if one was previously specified. The pending state of the default doorbell is transferred even when the INTID used for the doorbell is changed. Moving a vPE does not change the rules on generating default doorbells.

When VMOVP is issued, if DB==1, the vPE is marked as requesting Default Doorbell generation on the new target. When DB==0, the vPE is marked as not requesting Default Doorbell generation on the new target.

A command error occurs if any of the following apply:

• The PE specified by vPEID is not mapped to a Redistributor, using VMAPP.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

• A VMOVP specifies a value of Default_Doorbell_pINTID outside of the implemented LPI range, other than 1023. The command error code reported is 0x01_2206(VMOVP_PHYSICALID_OOR).

In this case, the ITS must take the actions described in Command errors.

VMOVP usage in GICv4.1

VMOVP usage in GICv4.1 is the same as in GICv4.0. See VMOVP usage for more information.

5.3.24 VSGI for GICv4.1 only

The vSGI command sets the configuration of a specified vSGI and optionally clears its pending state.

Figure 5-27 shows the format of the vSGI command.

Figure 5-27 vSGI command encoding

Where:

• E is the enable configuration.

  • Ignored when C==1.

• G is the group configuration.

  • Ignored when C==1.

• Priority, records bits [7:4] of the priority configuration.

  • Bits [3:0] are treated as 0b0000.

  • Ignored when C==1.

• vINTID and vPEID identify the interrupt.

• C is used to indicate whether the pending state of the interrupt should be cleared.

The following pseudocode describes the operation of the VSGI command:

// ITS.VSGI // =========

ITS.VSGI(ITSCommand cmd)
    if VCPUOutOfRange(cmd.VCPUID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError VSGI_VCPU_OOR";
UNPREDICTABLE;

VCPUTableEntry vte = ReadVCPUTable(UInt(cmd.VCPUID));

// It is CONSTRAINED UNPREDICTABLE whether ReadVCPUTable() can
// return mappings from other ITSs when mapping exists on current
// current ITS

if Valid then
   if (CMD.C==0) then
        // Set configuration of interrupt
        SetVirtualSGIConfiguration(cmd.VCPUID, vte, cmd.Intid, cmd.E, cmd.Priority, cmd.G);
   else
        // Clear pending state of interrupt
        ClearVirtualSGIPendingState(VCPUID, vte, cmdIntid);

IncrementReadPointer();
return;

5.3.25 VSYNC

This command ensures all outstanding ITS operations for the vPEID specified are globally observed before any further ITS commands are executed. Following the execution of a VSYNC the effects of all previous commands must apply to subsequent writes to GITS_TRANSLATER.

This command is provided only in GICv4.

Figure 5-28 shows the format of the VSYNC command.

Figure 5-28 VSYNC command format

In Figure 5-28:

• vPEID specifies the vPE for which commands must be synchronized.

• DW is the doubleword offset within a 32 byte, or four doubleword, ITS command packet.

The command and its arguments are:

VSYNC vPEID

A command error occurs if any of the following apply:

• If the PE specified by vPEID is not mapped to a Redistributor, using VMAPP GICv4.0.

• vPEID exceeds the maximum number supported by the ITS, as defined by GITS_BASER.

In this case, the ITS must take the actions described in Command errors.

The following pseudocode describes the operation of the VSYNC command:

// ITS.VSYNC // ========= ITS.VSYNC(ITSCommand cmd)
    if VCPUOutOfRange(cmd.VCPUID)
    then if GITS_TYPER.SEIS == '1'
    then IMPLEMENTATION_DEFINED "SError VSYNC_VCPU_OOR";
UNPREDICTABLE;

VCPUTableEntry vte = ReadVCPUTable(UInt(cmd.VCPUID));

if !vte.Valid then if GITS_TYPER.SEIS == '1' then IMPLEMENTATION_DEFINED "SError VSYNC_VCPU_INVALID"; UNPREDICTABLE;

bits(32) rd_base = vte.RDbase;

// Wait
    for the external effects of any virtual commands to be observable by all redistributors
// and ensure the internal effects of any previous commands affect any subsequent interrupt
// requests or commands WaitForVirtualCompletion(rd_base);

IncrementReadPointer();

return;

5.4 Common ITS pseudocode functions

The following terminology appears in some of the pseudocode functions in this section:

Interrupt Translation

An action that causes the ITS to attempt to set a particular pending bit in a particular table. Pending Interrupt

A particular pending bit is set in a particular table.

The pseudocode functions in this section are based on the following assumptions:

• Each ITS function must be performed as an atomic operation. Implementations must ensure that the observed behavior is consistent with that from a strictly atomic implementation.

• Where the pseudocode issues a sequence of read and write operations to a particular Redistributor, these operations must be performed in the order in which they were generated.

• Where the pseudocode issues a write to a particular Redistributor, operation does not need to wait for the completion of the write.

• Where the pseudocode issues write to memory to update a table, operation does not need to wait for the completion of these writes. A write to memory might never become visible to an external observer. However, the effect of any such writes must be ordered by any subsequent ITS operations, including the handling of interrupt translations. There are no ordering rules other than the standard rule that memory must appear as if writes to each location occurred in program order.

• Because each ITS function is performed as an atomic operation, any new interrupt translation that occurs after the function must be subject to the effects of that function.

• The effects of caching of the Redistributor LPI Configuration and LPI Pending tables are specified explicitly in the pseudocode.

• An interrupt translation might set a pending bit and pending bits remain set until handled by the PE. While an interrupt is pending it might be affected by an interrupt translation that is updated by a subsequent ITS function.

Note Some variable names used in the pseudocode differ from those used in the body text. For a list of the affected variables, see _Pseudocode terminology_B-910.

The following pseudocode invalidates any associated caching for the LPI configuration in the Redistributor for the specified translation.

// InvalidateByITE
// ===============
boolean InvalidateByITE(InterruptTableEntry ite)
if ite.Type == physical_interrupt then
    CollectionTableEntry cte = ReadCollectionTable(UInt(ite.ICID));
    if !cte.Valid then
        return FALSE;
    InvalidateInterruptCaches(ite.ICID, ite.OutputID);
else

VCPUTableEntry vte = ReadVCPUTable(UInt(ite.VCPUID));
if !vte.Valid then
    return FALSE;
InvalidateVirtualInterruptCaches(ite.VCPUID, ite.OutputID);
return TRUE;
The following pseudocode describes moving a pending interrupt.

The following pseudocode describes moving a pending interrupt.

// MovePendingState()
// ==================

MovePendingState(bits(32) rd1, bits(32) rd2, bits(32) ID)
    if IsPending(GICR_PENDBASER[rd1], ID) then
        // The interrupt is pending in the source redistributor

        // Make sure the interrupt is released or taken by the processor for
        // example by sending a clear and waiting for the response
        EnsureInterruptNotPendingOnProcessor(rd1, ID);

        if IsPending(GICR_PENDBASER[rd1], ID) then
            // The CPU released the interrupt and it is still pending
            // Note: the following must be done without any possibility of the
            // source redistributor re-forwarding the interrupt to the processor
            ClearPendingStateLocal(GICR_PENDBASER[rd1], ID);
            SetPendingStateLocal(GICR_PENDBASER[rd2], ID);

The following pseudocode describes moving a pending virtual interrupt.

// MoveVirtualPendingState()
// =========================

MoveVirtualPendingState(bits(32) rd_base, Address vpt1, Address vpt2, bits(32) ID)
    if IsPending(vpt1, ID) then
        // The interrupt is pending in the source redistributor

        // Make sure the interrupt is released or taken by the processor for example by sending a
        // VClear and waiting for the response
        EnsureVirtualInterruptNotPendingOnProcessor(rd_base, vpt1, ID);

        if IsPending(vpt1, ID) then
            // The CPU released the interrupt and it is still pending
            // Note: the following must be done without any possibility of the source redistributor
            // re-forwarding the interrupt to the processor
            ClearVirtualPendingStateLocal(vpt1, ID);
            SetVirtualPendingStateLocal(vpt2, ID);
    return;

The following pseudocode describes invalidating the caching of configuration data for the default doorbell
associated with a vPE.

// Invalidates any caching of configuration for the default
// doorbell associated with a vPE
InvalidateInterruptDoorbellCaches(UInt VCPUID, VCPUTableEntry vte);

// Sets the configuration of the specified vSGI
SetVirtualSGIConfiguration(UInt VCPUID, VCPUTableEntry vte, UInt Intid,
                           UInt Enable, UInt Priority, UInt Group);

// Clears the pending state of the specified vSGI
ClearVirtualSGIPendingState(UInt VCPUID, VCPUTableEntry vte, UInt Intid);

// Returns TRUE if the ITS supports GICv4.1
Boolean HasGIC41Ext();

The following pseudocode describes moving a pending virtual interrupt.

// MoveVirtualPendingState() // =========================
// The names of the Banked core registers.

enumeration RName {RName_0usr, RName_1usr, RName_2usr, RName_3usr, RName_4usr, RName_5usr,
                   RName_6usr, RName_7usr, RName_8usr, RName_8fiq, RName_9usr, RName_9fiq,
                   RName_10usr, RName_10fiq, RName_11usr, RName_11fiq, RName_12usr, RName_12fiq,
                   RName_SPusr, RName_SPfiq, RName_SPirq, RName_SPsvc,
                   RName_SPabt, RName_SPund, RName_SPmon, RName_SPhyp,
                   RName_LRusr, RName_LRfiq, RName_LRirq, RName_LRsvc,
                   RName_LRabt, RName_LRund, RName_LRmon,
                   RName_PC};

array bits(8) _Memory[0..0xFFFFFFFF];

Arrays are always explicitly declared, and there is no notation for a constant array. Arrays always contain at least
one element, because:
•      Enumerations always contain at least one symbolic constant.
•      Integer ranges always contain at least one integer.

Arrays do not usually appear directly in pseudocode. The items that syntactically look like arrays in pseudocode are
usually array-like functions such as R[i], MemU[address, size] or Elem[vector, i, size]. These functions package
up and abstract additional operations normally performed on accesses to the underlying arrays, such as register
banking, memory protection, endian-dependent byte ordering, exclusive-access housekeeping and Advanced SIMD
element processing.

The following pseudocode describes invalidating the caching of configuration data for the default doorbell associated with a vPE.

// Invalidates any caching of configuration for interrupts which are
// members of the collection specified by "collection"

InvalidateCollectionCaches(integer collection);

5.4.1 ITS helper functions

This subsection describes the ITS helper functions. These functions are placeholder functions for behavior that is not architected and that is IMPLEMENTATION DEFINED.

The functions are indicated by the hierarchical path names, for example shared/gic/its/its_helper:

• shared/gic/its/its_helper/Address.

• shared/gic/its/its_helper/ClearPendingState.

• shared/gic/its/its_helper/ClearPendingStateLocal.

• shared/gic/its/its_helper/CollectionOutOfRange.

• shared/gic/its/its_helper/CollectionTableEntry.

• shared/gic/its/its_helper/DeviceOutOfRange.

• shared/gic/its/its_helper/DeviceTableEntry.

• shared/gic/its/its_helper/EndOfCommand.

• shared/gic/its/its_helper/EnsureInterruptNotPendingOnProcessor.

• shared/gic/its/its_helper/EnsureVirtualInterruptNotPendingOnProcessor.

• shared/gic/its/its_helper/IdOutOfRange.

• shared/gic/its/its_helper/IncrementReadPointer.

• shared/gic/its/its_helper/InterruptTableEntry.

• shared/gic/its/its_helper/InterruptType.

• shared/gic/its/its_helper/InterruptType.

• shared/gic/its/its_helper/InvalidateInterruptCaches.

• shared/gic/its/its_helper/InvalidateInterruptConfigurationCaches.

• shared/gic/its/its_helper/InvalidateVCPUCaches.

• shared/gic/its/its_helper/InvalidateVirtualConfigurationCaches.

• shared/gic/its/its_helper/InvalidateVirtualInterruptCaches.

• shared/gic/its/its_helper/IsPending.

• shared/gic/its/its_helper/IsPending.

• shared/gic/its/its_helper/LPIOutOfRange.

• shared/gic/its/its_helper/MoveAllPendingState.

• shared/gic/its/its_helper/ReadCollectionTable.

• shared/gic/its/its_helper/ReadDeviceTable.

• shared/gic/its/its_helper/ReadTranslationTable.

• shared/gic/its/its_helper/ReadVCPUTable.

• shared/gic/its/its_helper/RetargetVirtualInterrupt.

• • shared/gic/its/its_helper/SetPendingState.

• shared/gic/its/its_helper/SetPendingStateLocal.

• shared/gic/its/its_helper/SizeOutOfRange.

• shared/gic/its/its_helper/VCPUOutOfRange.

• shared/gic/its/its_helper/VCPUTableEntry.

• shared/gic/its/its_helper/WaitForCompletion.

• shared/gic/its/its_helper/WaitForVirtualCompletion.

• • shared/gic/its/its_helper/WriteCollectionTable. • shared/gic/its/its_helper/WriteDeviceTable.

• shared/gic/its/its_helper/WriteTranslationTable.

• • shared/gic/its/its_helper/WriteVCPUTable.

shared/gic/its/its_helper/Address

// Address()
// ============

type Address = bits(48);

shared/gic/its/its_helper/ClearPendingState

// ClearPendingState()
// ===================
boolean ClearPendingState(InterruptTableEntry ite)
if ite.Type == physical_interrupt then
    CollectionTableEntry cte = ReadCollectionTable(UInt(ite.ICID));
    if (!cte.Valid) then
        return FALSE;
    bits(32) rd_base = cte.RDbase;
    ClearPendingStateLocal(GICR_PENDBASER[rd_base], ite.OutputID);
else
VCPUTableEntry vte = ReadVCPUTable(UInt(ite.VCPUID));
if (!vte.Valid) then
    return FALSE;
bits(32) rd_base = vte.RDbase;
Address vpt = vte.VPT_base;
ClearPendingStateLocal(vpt, ite.OutputID);
return TRUE;

shared/gic/its/its_helper/ClearPendingStateLocal

// ClearPendingStateLocal()
// =============================

// Clears the pending state of the physical interrupt specified by INTID
// for the redistributor which owns the LPI pending table specified by PendBase

ClearPendingStateLocal(PBType PendBase, bits(32) INTID);

// ClearVirtualPendingStateLocal()
// ============================

// Clears the pending state of the virtual interrupt specified by vINTID
// in the LPI pending table specified by base

ClearPendingStateLocal(Address base, bits(32) vINTID);

shared/gic/its/its_helper/CollectionOutOfRange

// CollectionOutOfRange()
// ================================

// Returns TRUE if the value supplied has bits above the implemented range
// or if the value exceeds the total number of collections supported in
// hardware and external memory

boolean CollectionOutOfRange(bits(16) collection);

shared/gic/its/its_helper/CollectionTableEntry

//CollectionTableEntry() // =======================

type CollectionTableEntry is ( boolean Valid, bits(32) RDbase )

shared/gic/its/its_helper/DeviceOutOfRange

// DeviceOutOfRange()
// =====================

// Returns TRUE if the value supplied has bits above the implemented range
// or if the value supplied exceeds the maximum configured size in the
// appropriate GITS_BASER<n>

boolean DeviceOutOfRange(bits(32) device);

shared/gic/its/its_helper/DeviceTableEntry

// DeviceTableEntry()
// =============

type DeviceTableEntry is (
    boolean Valid,
    Address ITT_base,
    bits(5) ITT_size
)

shared/gic/its/its_helper/EndOfCommand

// EndOfCommand()
// ================

// Terminate processing of the current command without incrementing the read pointer.
// This means the command will be run again.

EndOfCommand();

shared/gic/its/its_helper/EnsureInterruptNotPendingOnProcessor

// EnsureInterruptNotPendingOnProcessor()
// ======================================

// Returns when the physical interrupt specified by ID is not pending on
// the CPU interface connected to the redistributor specified by rd1

EnsureInterruptNotPendingOnProcessor(bits(32) rd1, bits(32) ID);

shared/gic/its/its_helper/EnsureVirtualInterruptNotPendingOnProcessor

// EnsureVirtualInterruptNotPendingOnProcessor()
// ==========================================

// Returns when the virtual interrupt specified by ID is not pending on
// the CPU interface connected to the redistributor specified by rd1

EnsureVirtualInterruptNotPendingOnProcessor(bits(32) rd1, Address vpt, bits(32) ID);

shared/gic/its/its_helper/IdOutOfRange

// IdOutOfRange()
// ============================

// Returns TRUE if the value supplied has bits above the implemented size or above the ITT_size

boolean IdOutOfRange(bits(32) ID, bits(5) ITT_size);

shared/gic/its/its_helper/IncrementReadPointer

// IncrementReadPointer()
// ===================

//Increments GITS_CREADR, wrapping if appropriate

IncrementReadPointer();

shared/gic/its/its_helper/InterruptTableEntry

// InterruptTableEntry()
// =====================

type InterruptTableEntry is (
boolean Valid,
InterruptType Type,
bits(32) OutputID,
bits(32) DoorbellID,
bits(16) ICID,
bits(16) VCPUID
)

shared/gic/its/its_helper/InterruptType

// InterruptType
// ====================

enumeration InterruptType { virtual_interrupt, physical_interrupt };

shared/gic/its/its_helper/InvalidateCollectionCaches

//InvalidateCollectionCaches() // =========================

// Invalidates any caching of configuration for interrupts which are // members of the collection specified by "collection"

InvalidateCollectionCaches(integer collection);

shared/gic/its/its_helper/InvalidateInterruptCaches

// InvalidateInterruptCaches()
// =============================

// Invalidates any caching of configuration for the physical
// interrupt specified by interruptID , which is a member of
// the collection specified by collection

InvalidateInterruptCaches(bits(16) collection, bits(32) interruptID);

shared/gic/its/its_helper/InvalidateInterruptConfigurationCaches

// InvalidateInterruptConfigurationCaches()
// ===================================

InvalidateInterruptConfigurationCaches(bits(32) ID, integer collection);

shared/gic/its/its_helper/InvalidateVCPUCaches

// InvalidateVCPUCaches()
// ==========================

// Invalidates any caching of configuration for the vPE specificed by vcpu_id

InvalidateVCPUCaches(integer vcpu_id);

shared/gic/its/its_helper/InvalidateVirtualConfigurationCaches

// InvalidateVirtualConfigurationCaches
// ================================

InvalidateVirtualConfigurationCaches(bits(32) ID, bits(16) VCPU);

shared/gic/its/its_helper/InvalidateVirtualInterruptCaches

// InvalidateVirtualInterruptCaches()
// =====================================

// Invalidates any caching of configuration for the virtual interrpt specified
// by the interruptID for the vPE specified by vcpi_id

InvalidateVirtualInterruptCaches(bits(16) vcpu_id, bits(32) interruptID);

shared/gic/its/its_helper/IsPending

// IsPending()
// ========================

// Returns TRUE if the virtual interrupt specified by interruptID
// is pending in the LPI pending table specified by base

boolean IsPending(Address base, bits(32) interruptID);

shared/gic/its/its_helper/IsPending

// IsPending()

// ========================
// Returns TRUE if the value supplied has bits above the implemented range or
// if the value supplied exceeds the maximum configured size in the
// appropriate GITS_BASERn

boolean VCPUOutOfRange(bits(16) vcpu);

shared/gic/its/its_helper/LPIOutOfRange

//LPIOutOfRange()

// ==========================

// Returns TRUE if the value supplied is larger than that permitted by GICD_TYPER.IDbits or not in the // LPI range and is not 1023

boolean LPIOutOfRange(bits(32) ID);

shared/gic/its/its_helper/MoveAllPendingState

// MoveAllPendingState()
// ===================

// Moves the pending state of all interrupts from the Redistributor specified by rd1
// to the Redistributor specified by rd2

MoveAllPendingState(bits(32) rd1, bits(32) rd2);

shared/gic/its/its_helper/ReadCollectionTable

// ReadCollectionTableEntry()
// =========================

// Reads a collection table entry from memory

CollectionTableEntry ReadCollectionTable(integer index);

shared/gic/its/its_helper/ReadDeviceTable

// ReadDevicePointer()
// ==========================

// Reads a device table entry from memory

DeviceTableEntry ReadDeviceTable(integer index);

shared/gic/its/its_helper/ReadTranslationTable

// ReadTranslationTable()
// =======================
// Reads a VCPU table entry from memory

VCPUTableEntry ReadVCPUTable(integer index);

shared/gic/its/its_helper/ReadVCPUTable

//ReadVCPUTable() // ===========================

// Reads a VCPU table entry from memory

VCPUTableEntry ReadVCPUTable(integer index);

shared/gic/its/its_helper/RetargetVirtualInterrupt

// RetargetVirtualInterrupt()
// =======================

RetargetVirtualInterrupt(integer device, bits(32) ID, integer vcpu);

shared/gic/its/its_helper/SetPendingState

// SetPendingState()
// =================

boolean SetPendingState(InterruptTableEntry ite)

     if ite.Type == physical_interrupt then
         CollectionTableEntry cte = ReadCollectionTable(UInt(ite.ICID));

         if !cte.Valid then
             return FALSE;

         bits(32) rd_base = cte.RDbase;

         SetPendingStateLocal(GICR_PENDBASER[rd_base], ite.OutputID);

     else
         VCPUTableEntry vte = ReadVCPUTable(UInt(ite.VCPUID));

         if !vte.Valid then
             return FALSE;

         bits(32) rd_base = vte.RDbase;
         Address vpt = vte.VPT_base;

         SetVirutalPendingStateLocal(vpt, ite.OutputID);

         if (GICR_VPENDBASER[rd_base].Valid == '1' &&
             GICR_VPENDBASER[rd_base].PhysicalAddress != vpt<47:16>) then
             if ite.DoorbellID != ZeroExtend(INTID_SPURIOUS, 32) then
                 // Not resident so set the doorbell interrupt pending as well
                 SetPendingStateLocal(GICR_PENDBASER[rd_base], ite.DoorbellID);

     return TRUE;

shared/gic/its/its_helper/SetPendingStateLocal

// SetPendingStateLocal()
// =======================

// Sets the pending state of the physical interrupt specified by INTID
// for the Redistributor that owns the LPI pending table specified by PendBase

SetPendingStateLocal(PBType PendBase, bits(32) INTID);

// SetVirtualPendingStateLocal()
// =======================

// Sets the pending state of the virtual interupt specified by INTID
// in the LPI pending table specified by base

SetPendingStateLocal(Address base, bits(32)INTID);

shared/gic/its/its_helper/SizeOutOfRange

// SizeOutOfRange()
// =====================

// Returns TRUE if the value supplied exceeds the maximum allowed by GITS_TYPER.ID_bits

boolean SizeOutOfRange(bits(5) ITT_size);

shared/gic/its/its_helper/VCPUOutOfRange

// VCPUOutOfRange()
// =======================

shared/gic/its/its_helper/VCPUTableEntry

//VCPUTableEntry() // ==================

type VCPUTableEntry is ( boolean Valid, bits(32) RDbase, Address VPT_base, bits(5) VPT_size )

shared/gic/its/its_helper/WaitForCompletion

// WaitForCompletion()
// ============================

// Returns when all external effects of any phsical commands are observable
// by all Redistributors and the internal effects of any previous
// commands affect any subsequent interrupt requests or commands

WaitForCompletion(bits(32) RDbase);

shared/gic/its/its_helper/WaitForVirtualCompletion

// WaitForVirtualCompletion()
// =======================

WaitForVirtualCompletion(bits(32) RDbase);

shared/gic/its/its_helper/WriteCollectionTable

//WriteCollectionTable() // =========================

// Writes a collection table entry to memory

WriteCollectionTable(integer index, CollectionTableEntry cte);

shared/gic/its/its_helper/WriteDeviceTable

// WriteDeviceTable()
// ========================

// Writes a device table entry to memory

WriteDeviceTable(integer index, DeviceTableEntry dte);

shared/gic/its/its_helper/WriteTranslationTable

// WriteTranslationTable()
// ================================

// Writes an ITT table entry to memory

WriteTranslationTable(Address base, integer index, InterruptTableEntry cte);

shared/gic/its/its_helper/WriteVCPUTable

// WriteVCPUTable()
// ===============================

// Writes a VCPU table entry to memory

WriteVCPUTable(integer index, VCPUTableEntry vte);

5.5 ITS command error encodings

When an ITS supports system errors, that is when GITS_TYPER.SEIS == 1, ITS command errors can be reported to software. It is IMPLEMENTATION DEFINED how these errors are recorded and reported.

Table 5-8 shows the ITS command error encodings.

5.6 ITS power management

This subsection describes the software sequences for enabling and disabling an ITS. It contains the following sections:

• Enabling an ITS .

• Disabling an ITS .

5.6.1 Enabling an ITS

On power up, an ITS is reset to the quiescent state where GITS_CTLR.Quiescent == 1 and GITS_CTLR.Enabled == 0. To enable an ITS, software must:

1. Ensure any memory structures required to support the device, interrupt translation, interrupt collection, or virtual CPU tables are initialized or restored.

2. Ensure that the ITS command queue has been provisioned.

3. Set GITS_CTLR.Enabled to 1.

4. Configure the ITS as required using the appropriate ITS commands. For more information about the ITS commands, see ITS commands.

5.6.2 Disabling an ITS

To disable an ITS, software must:

1. Ensure that all interrupts that target the ITS that is being powered down are either redirected or disabled.

2. Disable the ITS by clearing GITS_CTLR.Enable to 0. The disabled ITS completes all outstanding operations and then sets GITS_CTLR.Quiescent to 1.

3. Ensure the ITS is quiescent by polling until GITS_CTLR.Quiescent == 1.

When GITS_CTLR.Enable == 0, write accesses to GITS_TRANSLATER are ignored. When GITS_CTLR.Quiescent == 1, all operations have completed and memory backed state is committed. The ITS can then be powered down to an IMPLEMENTATION DEFINED state.

Chapter 6: Virtual Interrupt Handling and Prioritization

This chapter describes the fundamental aspects of GIC virtual interrupt handling and prioritization:

• About GIC support for virtualization .

• Operation overview .

• Configuration and control of VMs .

• Pseudocode .

6.1 About GIC support for virtualization

An operating system that is executing at EL1 under the control of a hypervisor executing at EL2 is sometimes referred as a virtual machine (VM). A VM can support multiprocessing, which means that multiple virtual PEs (vPEs), that are scheduled by the hypervisor are executing on one or more physical PEs. When a vPE is executing on a PE, that vPE of the VM is referred to as being scheduled on the physical PE.

In Armv8, when EL2 is implemented and enabled, the CPU interface provides mechanisms to minimize the hypervisor overhead of routing interrupts to a VM. For more information about vPEs, see Operation overview .

For more information about EL2 and virtual interrupts, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

In GICv4, for the directly injected virtual LPIs, the scheduled vPE is determined by GICR_VPENDBASER. For more information, see Doorbell interrupts .

Note The GIC does not provide additional mechanisms for the virtualization of the GICD_, GICR_, and GITS_* registers. To virtualize VM accesses to these registers, the hypervisor must set stage 2 Data Aborts to those memory locations so that the hypervisor can emulate these effects. For more information about stage 2 Data Aborts, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

When a GIC provides support for virtualization, the VM operates in an environment that has the following features:

• The vPE can be configured to receive virtual Group 0 interrupts.

• The vPE can be configured to receive virtual Group 1 interrupts.

• Virtual Group 0 interrupts are signaled using the virtual FIQ signal to Non-secure EL1.

• Virtual Group 1 interrupts are signaled using the virtual IRQ signal to Non-secure EL1.

• Virtual interrupts can be handled by the vPE as if they were physical interrupts.

Note

This applies when affinity routing and System register access are enabled. For information about support for virtual interrupts in legacy operation, see Support for legacy operation of VMs .

EL2 controls the generation of virtual interrupts for a VM. This allows software executing at EL2 to:

• Generate virtual Group 0 and Group 1 interrupts for the vPE.

• Save and restore the interrupt state of the vPE.

• Control the prioritization of the virtual interrupts.

• Change the vPE that is scheduled.

GICv4 introduces the ability to present virtual LPIs from an ITS directly to a vPE, without hypervisor intervention.

Handling virtual interrupts in legacy operation requires a GICV_* memory-mapped interface. See Support for legacy operation of VMs for more information.

6.2 Operation overview

GICv3 supports the Armv8-A virtualization functionality. A hypervisor executing at EL2 uses the ICH_* System register interface to configure and control a virtual PE (vPE) executing at EL1. For information about the VM control interface, see Configuration and control of VMs . A vPE uses the ICC_*_EL1 System register interface to communicate with the GIC. The configuration of HCR_EL2.{IMO, FMO} determines whether the virtual or the physical interface registers are accessed.

Note This chapter describes the handling of virtual interrupts in the context of the AArch64 state with System register access enabled. The individual AArch64 System register descriptions that are cross-referenced in this chapter contain a reference to the AArch32 System register that provides the same functionality. For information about VMs in legacy operation, see Support for legacy operation of VMs .

Software executing at EL3 or EL2 configures the PE to route physical interrupts to EL2. The interrupt can be:

• An interrupt targeting a vPE. The hypervisor sets the corresponding virtual INTID to the pending state on the target vPE and includes the information about the associated physical INTID. When the vPE is not scheduled on a PE, the hypervisor might choose to reschedule the vPE. Otherwise the interrupt is left pending on the vPE for scheduling by the hypervisor at a later time.

• An interrupt targeting the hypervisor. This interrupt might:

  • Have been generated by the system.

  • Be a maintenance interrupt associated with a scheduled VM. See Maintenance interrupts for more details.

  • In GICv4, be a doorbell interrupt from an ITS. In GICv4, a virtual interrupt can be presented to a vPE without hypervisor involvement. A doorbell interrupt must be generated when a virtual interrupt is made pending for a vPE but the vPE is not scheduled on a PE.

The hypervisor handles physical interrupts according to the rules described in Chapter 4 Physical Interrupt Handling and Prioritization before they are virtualized. For information about the handling of physical interrupts and their virtualization during legacy operation, see Chapter 14 Legacy Operation and Asymmetric Configurations .

The GIC virtualization support includes a list of virtual interrupts for a vPE that is stored in hardware List registers, see Usage model for the List registers . Each entry in the list corresponds to either a pending or an active interrupt, and the entry describes the virtual interrupt number, the interrupt group, the interrupt state, and the virtual priority of the interrupt. A virtual interrupt described in the list entry can be configured to be associated with a physical SPI or PPI.

The GIC implementation selects the highest priority pending virtual interrupt from the list of interrupts held in the List registers and, if it is of sufficient virtual priority compared to the active virtual interrupts and virtual priority mask, presents it as either a virtual FIQ or a virtual IRQ, depending on the group of the interrupt. The virtual CPU interface controls apply to the virtual interrupt in the same way as the physical interrupt controls apply to the physical interrupt. Therefore, using the virtual CPU interface controls, software executing on the vPE can:

• Set the virtual priority mask.

• Control how the virtual priority is split between the group priority and the subpriority.

• Acknowledge a virtual interrupt.

• Perform a priority drop on the virtual interrupt.

• Deactivate the virtual interrupt.

The virtual CPU interface supports both EOImodes, so that a virtual EOI can perform a priority drop alone, or a combined priority drop and deactivation.

When a virtual interrupt is acknowledged, then the state of the virtual interrupt changes from pending to active in the corresponding List register entry.

When a virtual interrupt is deactivated, then the state of the virtual interrupt changes from active to inactive, or from active and pending to pending, in the corresponding List register entry. If the virtual interrupt is associated with a physical interrupt, then the associated physical interrupt is deactivated. Virtual interrupts taken to EL1 are handled in a similar manner to physical interrupts that are handled in a system with a single Security state, that is where GICD_CTLR.DS is set to 1:

• Group 0 interrupts are signaled using the virtual FIQ signal.

• Group 1 interrupts are signaled using the virtual IRQ signal.

• Group 0 and Group 1 interrupts share an interrupt prioritization and preemption scheme. A minimum of 32 and a maximum of 256 priority levels are supported, as determined by the values in ICH_VTR_EL2.

Note The priority value is not subject to the shift used for Non-secure physical interrupts. While virtualization supports up to 8 bits of priority, a minimum of 5 and a maximum of 8 bits must be implemented.

Note For information about the rules governing exception entry on an Armv8-A PE, see Arm[®] Architecture Reference Manual, Armv8, for Armv8-A architecture profile .

Accesses at EL1 to Group 0 registers are virtual when:

• The current Security state is Non-secure and HCR_EL2.FMO == 1.

• The current Security state is Secure, HCR_EL2.FMO == 1 and SCR_EL3.EEL2 == 1.

Virtual accesses to the following Group 0 ICC_* registers access the ICV_* equivalents:

• Accesses to ICC_AP0R_EL1 access ICV_AP0R_EL1.

• Accesses to ICC_BPR0_EL1 access ICV_BPR0_EL1.

• Accesses to ICC_EOIR0_EL1 access ICV_EOIR0_EL1.

• Accesses to ICC_HPPIR0_EL1 access ICV_HPPIR0_EL1.

• Accesses to ICC_IAR0_EL1 access ICV_IAR0_EL1.

• Accesses to ICC_IGRPEN0_EL1 access ICV_IGRPEN0_EL1.

Accesses at EL1 to Group 1 registers are virtual when:

• The current Security state is Non-secure and HCR_EL2.IMO == 1.

• The current Security state is Secure, HCR_EL2.IMO == 1 and SCR_EL3.EEL2 == 1.

Virtual accesses to the following Group 1 ICC_* registers access the ICV_* equivalents:

• Accesses to ICC_AP1R_EL1 access ICV_AP1R_EL1.

• Accesses to ICC_BPR1_EL1 access ICV_BPR1_EL1.

• Accesses to ICC_EOIR1_EL1 access ICV_EOIR1_EL1.

• Accesses to ICC_HPPIR1_EL1 access ICV_HPPIR1_EL1.

• Accesses to ICC_IAR1_EL1 access ICV_IAR1_EL1.

• Accesses to ICC_IGRPEN1_EL1 access ICV_IGRPEN1_EL1.