Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Chapter 8: GICv4.1 Virtual Interrupt Support

This chapter describes the fundamental aspects of GICv4.1 virtual interrupt handling and prioritization:

  • About GICv4.1 virtual interrupt support .

  • Changes to the CPU interface .

  • ITS commands .

  • vPEID width .

  • Doorbells .

  • vPE residency and locating data structures .

  • Register based vLPI invalidation .

  • Direct injection of vSGIs .

8.1 About GICv4.1 virtual interrupt support

GICv4.1 extends support for direct injection of virtual interrupts to SGIs. It makes direct injection simpler and more efficient for software to use through the following changes:

  • A structure to track the pending and configuration tables for all active vPEs.

  • Register-based invalidation options for virtual interrupt configuration.

  • Modifications to simplify the recovery of memory allocated to the GIC when no longer in use.

Support for legacy mode is obsolete in GICv4.1 and the ARE bits are RES1.

8.2 Changes to the CPU interface

GICv4.1 introduces changes to the CPU interface.

ID_AA64PFR0_EL1.GIC==b0011 indicates support for GICv4.1.

Delivering a vSGI to a PE with ID_AA64PFR0_EL1.GIC==b0001 is CONSTRAINED UNPREDICTABLE:

  • The interrupt is ignored.

  • The interrupt is delivered.

ICH_HCR_EL2.vSGIEOICount controls whether deactivations of vSGIs increment ICH_HCR_EL2.EOIcount.

8.3 ITS commands

Specifying a vPEID beyond the implemented range in any ITS command is CONSTRAINED UNPREDICTABLE, with two options:

  • A command error is generated.

  • The ITS ignores unimplemented vPEID bits.

Specifying a vPEID beyond the configured vPEID size generates a command error in most commands.

8.4 vPEID width

GICv4.1 permits vPEID widths of between 1 and 16 bits. The VIL and VID fields in GICD_TYPER2 together report the implemented vPEID width.

Software can configure a smaller vPEID width when allocating the Redistributor vPE Configuration Tables and ITS vPE Tables.

8.5 Doorbells

The Doorbell mechanism supported in GICv4.0 is referred to as Individual doorbells in GICv4.1. Doorbell interrupts target the Redistributor the vPE is currently mapped to, based on the previous VMAPP or VMOVP command for the vPE.

8.5.1 Individual doorbells

Support for individual doorbells is IMPLEMENTATION DEFINED in GICv4.1 and reported by GITS_TYPER.nID. All ITSs connected to a single GIC have the same value of GITS_TYPER.nID.

When GITS_TYPER.nID==1, the Dbell_pINTID field in VMAPTI and VMAPI is treated as being 1023.

When a vLPI from the ITS becomes pending, an individual doorbell interrupt is generated if all of the following conditions apply:

  • GITS_TYPER.nID==0

  • The target vPE is not scheduled.

  • An individual doorbell pINTID was supplied by the ITS mapping for the EventID/DeviceID combination.

Virtual SGIs cannot trigger individual doorbells and it is IMPLEMENTATION DEFINED whether a virtual interrupt that triggers an individual doorbell also triggers a default doorbell.

8.5.2 Default doorbells

GICv4.1 provides a new default doorbell per vPEID, specified as part of the VMAPP command.

When an EventID or a DeviceID is mapped to a virtual interrupt, a doorbell INTID can be specified in the VMAPI or VMAPTI command. If no doorbell is specified, the default doorbell for the vPE is used, if one was specified.

A default doorbell interrupt is generated when all of the following conditions are met:

  • A virtual interrupt, which is individually enabled, becomes pending, or a virtual interrupt becomes enabled while pending.

    • It is IMPLEMENTATION DEFINED whether the GIC factors in the Group enables from GICR_VPENDBASER when the vPE was last scheduled. For vPEs that have never been scheduled, the Group enables are treated as being 1.

  • The vPE is not scheduled.

  • When that vPE was last made non-scheduled, GICR_VPENDBASER.doorbell was written as 0b1

    • When a vPE is created, it is treated as being made non-scheduled with GICR_VPENDBASER.doorbell written as 0b1.

Note In some circumstances GICR_VPENDBASER.doorbell behaves as if 0b0 even when written as 0b1, refer to the register description.

  • A default doorbell was supplied by the ITS mapping for the vPEID.

  • The default doorbell for this vPE has not been acknowledged since the vPE was last made non-resident.

If the default doorbell for a vPE is pending, but there are no individually enabled and pending interrupts for the vPE, it is IMPLEMENTATION DEFINED whether the pending state of the default doorbell is cleared.

If the virtual interrupt is individually disabled, or part of a disabled Group, no default doorbell interrupt is generated. This is different to GICv4.0, where doorbell generation was independent of the enabled state of the vLPI.

GICR_VPENDBASER.doorbell allows a software to indicate to the IRI whether default doorbells are to be generated for the vPE. It does not affect the generation of individual doorbells. Between being made non-scheduled and then being made scheduled, a default doorbell of a vPE is set to pending at most once. The default doorbell for a vPE might be set to pending speculatively, if all the conditions other than the arrival of a virtual interrupt are met. This does not override the requirement that a default doorbell is only set to pending at most once between being residences. Setting a vPE as scheduled clears the pending state of its default doorbell.

8.6 vPE residency and locating data structures

A vPE Configuration table stores the locations of each vPE LPI Configuration and Pending table. The GICR_VPROPBASER register on each Redistributor points to the vPE Configuration table, and vPEID indexes the table. A vPE is scheduled by writing its vPEID to GICR_VPENDBASER, selecting an entry from the vPE Configuration table. A system can contain multiple copies of the vPE Configuration table. This structure is shown in Figure 8-1.

Image text

vLPI
Configuration
table
vPE Configuration table
vLPI
Valid entry Pending
Redistributor Invalid entry table
Invalid entry
GICR_VPROPBASER Valid entry
vLPI
Configuration
table
vLPI
Pending
table
vPEID

**Figure 8-1 Redistributor and the vPE Configuration Table**

8.6.1 vPE Configuration table

The format of the vPE Configuration table is IMPLEMENTATION DEFINED. GICR_VPROPBASER.Z indicates whether the table contains all zeros. If the vPE Configuration table does not contain all zeros on initial allocation, the behavior is UNPREDICTABLE. When GICR_VPROPBASER.Z==0, the memory contents are not zero and contain valid data.

GICR_VPROPBASER.Valid indicates whether the vPE Configuration table is valid. If the vPE Configuration table is written by any agent other than the GIC when any Redistributor pointing at that table has GICR_VPROPBASER.Valid==1, the behavior is UNPREDICTABLE. When no Redistributor with GICR_VPROPBASER.Valid==1 has a pointer to a vPE Configuration Table, there are no cached copies of that vPE Configuration Table in any Redistributor.

When GICR_VPROPBASER.Valid is written from 1 to 0, all other read/write fields in the register become UNKNOWN. After writing GICR_VPROPBASER.Valid from 1 to 0, when GICR_CTLR.RWP==0, there are no further accesses to the vPE Configuration Table by that Redistributor.

GICR_VPROPBASER.Valid can be written from 1 to 0 while another Redistributor in the same CommonLPIAff group has GICR_CTLR.RWP==1 due a previous write of GICR_VPROPBASER.Valid from 1 to 0. If GICR_VPROPBASER.Valid is written from 0 to 1 when any Redistributor in the same CommonLPIAff group has GICR_CTLR.RWP==1 due a previous write of Valid from 1 to 0, the result is UNPREDICTABLE.

Writing GICR_VPROPBASER when GICR_CTLR.RWP==1 due a previous write of GICR_VPROPBASER.Valid from 1 to 0 on that Redistributor causes UNPREDICTABLE behavior.

Note The vPE Configuration Table is populated as a side effect of the VMAPP commands issued through the ITS. It is not intended to be accessed directly by software.

8.6.2 Residency and mapping restrictions

If the target Redistributor has GICR_VPROPBASER.Valid==0, a VMAPP command with V==1 has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The mapping is discarded.

  • The mapping is made using the vPE Configuration Table from an UNKNOWN Redistributor with GICR_VPROPBASER.Valid==1.

If the target Redistributor has GICR_VPROPBASER.Valid==0, a VMOVP command has one of the following

CONSTRAINED UNPREDICTABLE effects:

  • The mapping is not moved.

  • The mapping is moved.

  • The mapping is discarded.

If the specified vPEID is beyond the range of the vPE Configuration table, a VMAPP command with V==1 has one of the following CONSTRAINED UNPREDICTABLE effects unless the command causes a command error:

  • The command is ignored.

  • The vPEID is treated as an UNKNOWN legal value.

If the specified vPEID is beyond the range of the vPE Configuration table, a VMOVP command has one of the following CONSTRAINED UNPREDICTABLE effects unless the command causes a command error:

  • The command is ignored.

  • The vPEID is treated as an UNKNOWN legal value.

If there are any ITS vPEID mappings that target the Redistributor, the effect of clearing GICR_VPROPBASER.Valid from 1 to 0 is UNPREDICTABLE.

Note Arm strongly recommends that all vPE mappings are removed from a Redistributor before clearing GICR_VPROPBASER.Valid.

If a vPEID is scheduled on multiple Redistributors at the same time, the effect is UNPREDICTABLE.

If a vPEID is scheduled on any Redistributor when there is no current ITS mapping for that vPEID, one of the following CONSTRAINED UNPREDICTABLE effects occurs:

  • GICR_VPENDBASER.vPEID is treated as having an UNKNOWN valid value for all purposes other than a direct read of the register.

  • GICR_VPENDBASER.Valid is treated as being set to 0 for all purposes other than a direct read of the register.

  • The vPEID is treated as mapped with an UNKNOWN configuration.

A vPEID can be scheduled on the Redistributor it is mapped to in the ITSs, or any other Redistributor within the same CommonLPIAff group. Scheduling a vPEID on a Redistributor in a different CommonLPIAff group has one of the following CONSTRAINED UNPREDICTABLE effects:

  • Pending interrupts are not delivered.

  • Interrupts are delivered that are not pending.

  • Incorrect configuration might be used for interrupts.

  • The guarantees on doorbell interrupts might not be respected.

If a vPEID is scheduled on any Redistributor when a VMOVP is issued for it, the result is UNPREDICTABLE.

8.7 Register based vLPI invalidation

Cached configuration data of a specific LPI can be invalidated using the GICR_INVLPIR register, or all LPIs using the GICR_INVALLR register, as follows:

  • Writing GICR_INVLPIR.V == 0 or GICR_INVALLR.V == 0 performs the invalidation on the physical INTID space.

  • Writing GICR_INVLPIR.V == 1 or GICR_INVALLR.V == 1 performs the invalidation on the virtual INTID space identified by the GICR_INVLPIR.vPEID or GICR_INVALLR.vPEID field, respectively.

When writing GICR_INVLPIR.V == 1, the invalidation operation has no effect when any of the following occur:

  • The GICR_INVLPIR.INTID field is outside the supported LPI range for that vPE.

  • The GICR_INVLPIR.INTID field is not an LPI.

Issuing a register-based invalidation operation for a vPEID not mapped to that Redistributor, or another Redistributor within the same CommonLPIAff group, has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The operation is ignored.

  • The invalidation is completed affecting an UNKNOWN subset of the Redistributors.

  • The invalidation is completed affecting all Redistributors.

When writing GICR_INVLPIR or GICR_INVALLR, GICR_SYNCR.Busy tracks invalidates issued on the same Redistributor:

  • GICR_SYNCR.Busy == 1 until the invalidation completes.

  • When GICR_SYNCR.Busy == 0, the invalidate is complete and the effects of the invalidation are visible on all Redistributors, unless specified otherwise.

Writing GICR_INVLPIR or GICR_INVALLR when GICR_SYNCR.Busy==1 has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The write is IGNORED.

  • The invalidate specified by the write is performed.

The effect of register based invalidate is only guaranteed to be visible to an ITS command after GICR_SYNCR records it as complete. Issuing an ITS command when there is an outstanding register based invalidate for an affected interrupt has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The effect of the invalidate is applied before the ITS command.

  • The invalidate is ignored.

Issuing a register based invalidate for an interrupt when there is an outstanding ITS command that affects the interrupt has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The effect of the invalidate is applied before the ITS command.

  • The effect of the invalidate is applied after the ITS command.

  • The invalidate is ignored.

The GICR_INVLPIR, GICR_INVALLR, and GICR_SYNCR registers are mandatory in GICv4.1.

8.8 Direct injection of vSGIs

A new mechanism is introduced to allow SGIs to be directly injected via the ITS. This mechanism still requires a trap to the hypervisor on the sending PE but removes the need for a trap to the hypervisor on the receiving PE(s). There are limitations on these controls:

  • The ITS controls must only be used on an ITS that has a mapping for that vPEID.

    • Where multiple ITSs have a mapping for the vPEID, any ITS with a mapping may be used.

  • The Redistributor controls must only be used on the currently targeted Redistributor, or on a Redistributor within the same CommonLPIAff group. The vPEID does not need to be currently scheduled, only mapped.

    • Where multiple ITSs have a mapping for the vPEID, any ITS with a mapping may be used.

Failure to follow these guidelines can lead to UNPREDICTABLE behaviors.

There is no control to query the current configuration of a vSGI. Software must keep its own copy of the current configuration of a vSGI to emulate reads of the GICR_IxxxR0 SGI configuration fields. vSGIs received through direct injection do not have an Active state.

8.8.1 Generating a vSGI

When GITS_CTLR.Enabled==1 and GITS_CTLR.Quiescent==0, a write to GITS_SGIR results in a virtual interrupt being generated with the vPEID and vINTID from the write. If the vPEID is not mapped on any ITS, the write is silently discarded. If the vPEID is not mapped on this ITS, but is mapped on a different ITS, it is CONSTRAINED UNPREDICTABLE whether the interrupt is delivered or discarded. Virtual SGIs have no priority shift.

8.8.2 Storing vSGI state and configuration

The last 128 bits of the IMPLEMENTATION DEFINED region in the Virtual LPI Pending Table are redefined for use storing SGI configuration and state. The format of this space is:

Table 8-1 Virtual LPI Pending Table

| 31 | 24 23 | 16 | 15 | 8 7 | 0 | Offset from start of Pending Table | |—|— Enable RES0 |—|—|— Pending Group |—|— +0x3F0 +0x3F4 | | PRI_7 | PRI_6 PRI_5 | PRI_4 | PRI_3 | PRI_2 PRI_1 | PRI_0 | +0x3F8 | | PRI_15 | PRI_14 PRI_13 | PRI_12 | PRI_11 | PRI_10 PRI_9 | PRI_8 | +0x3FC |

  • Pending[n]: The pending state of vSGI n:

    • 0 - Not pending.

    • 1 - Pending.

  • Enable[n]: The enable state of vSGI n:

    • 0 - Disabled.

    • 1 - Enabled.

  • Group[n]: The Group of vSGI n:

    • Group 0.

    • Group 1.

PRI_: Bits [7:4] of vSGI’s priority, bits [3:0] are treated as b0000.

8.8.3 Emulating GICR_I[C|S]PENDR0

Writing GICR_VSGIR queries the pending state of the virtual SGIs belonging to the specified vPE. GICR_VSGIPENDR.Busy determines when the query is complete, as follows:

  • GICR_VSGIPENDR.Busy == 1 until the query completes.

  • When GICR_VSGIPENDR.Busy == 0, the pending state of the vSGIs belonging to that vPE is reported in GICR_VSGIPENDR.Pending.

GICR_VSGIRPEND.Pending returns an UNKNOWN value in the following cases:

  • When GICR_VSGIPENDR.Busy == 1.

  • Writing a vPEID that is invalid or that is not mapped to this CommonLPIAff Redistributor group.

Writing GICR_VSGIR when GICR_VSGIPENDR.Busy == 1 has one of the following CONSTRAINED UNPREDICTABLE effects:

  • The write is ignored.

  • The write causes a fresh look up to occur.

The VSGI command allows writes to GICR_ISPENDR0 to be emulated. Writes to GICR_ISPENDR0 can be emulated using GITS_SGIR.