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 7: GICv4.0 Virtual LPI Support

This chapter describes the fundamental aspects of GICv4.0 virtual LPI support:

  • About GICv4.0 virtual Locality-specific Peripheral Interrupt support .

  • Direct injection of virtual interrupts .

7.1 About GICv4.0 virtual Locality-specific Peripheral Interrupt support

In GICv3, the hypervisor uses the System registers to present LPIs to a virtualized system. A virtual LPI (vLPI) is generated when the hypervisor writes a vINTID corresponding to the LPI range, to a List register, in this case, the vINTID that has a value greater than 8191. As an LPI does not have an active state, it is not possible to associate a virtual LPI with a physical interrupt.

GICv4 provides support for the direct injection of vLPIs, in the LPI INTID range. With the direct injection of vLPIs, the GICR_* registers use structures in memory for each vPE to hold LPI configuration and pending information for vLPIs in the same way that they use structures in memory to hold LPI configuration and pending information for physical LPIs.

However, the virtual structures are different from the physical structures, with the vLPI tables for the current vPE scheduled on a PE by GICR_VPENDBASER and GICR_VPROPBASER in the Redistributor associated with that PE. For more information about the physical LPI tables, see LPI Configuration tables and LPI Pending tables .

When scheduling a vPE, GICR_VPENDBASER.IDAI can be cleared to 0:

  • When the vPE was last scheduled on a Redistributor on the same GIC.

  • When the vPE is scheduled for the first time after the initial allocation, and the entire virtual LPI Pending table contained only zeros on initial allocation.

  • In IMPLEMENTATION DEFINED cases.

Clearing GICR_VPENDBASER.IDAI to 0 at any other time results in UNPREDICTABLE behavior.

The Redistributor associated with the PE on which the vPE is scheduled determines the highest priority pending vLPI, and forwards this to the virtual CPU interface of the vPE. This vLPI and the interrupts in the List register are then prioritized together to determine the highest priority pending virtual interrupt for the vPE.

For information about virtual LPIs and the virtual CPU tables, see The vPE table .

7.2 Direct injection of virtual interrupts

The ITS maps an EventID and a DeviceID to an INTID associated with a PE, see The Interrupt Translation Service for more information. GICv4 introduces the ability to generate a virtual LPI without involving the hypervisor. In this case, an ITS maps the EventID for the interrupt translation using the following mechanism:

  • The ITS interruption translation table entry for a vLPI is configured with:

    • A control flag that indicates that the EventID is associated with a virtual LPI.

  • A vPEID to index in to the ITS vPE table. For more information about vPEID and the vPE table, see The vPE table . The vPE table provides the base address of the GICR_* registers in the format defined by GITS_TYPER.PTA and the base address of the virtual LPI Pending table associated with the target VM.

    • A virtual INTID (vINTID) that indicates which vLPI becomes pending.

  • A physical INTID (pINTID) that can be used as a doorbell interrupt to the hypervisor if the vPE is not scheduled on a PE. The value 1023 is used where a doorbell interrupt is not required, otherwise an INTID in the physical LPI range must be provided.

When EL3 is present:

  • Virtual interrupts received by direct-injection are only considered when determining the highest priority pending virtual interrupt in Non-secure state.

  • Directly-injected virtual interrupts are not signaled as exceptions in Secure state or reported through ICV registers.

Note When an implementation uses the GIC Stream protocol, there is no restriction on the IRI sending VSET commands while the PE is in Secure state. However, the PE does not signal these interrupts as exceptions while in Secure state, even when SCR_EL3.EEL2==1.

When EL3 is not present:

  • Virtual LPIs that are received by direct injection can be signaled in whichever Security state the PE supports.

For more information about:

  • Physical LPIs, see LPIs .

  • The ITS and format of an Interrupt translation table (ITT), see The Interrupt Translation Service .

  • The commands used to control the handling of virtual LPIs associated with an ITS, see Table 5-6 and the following commands:

    • VINVALL .

  • VMAPI .

    • VMAPP GICv4.0 .

  • VMAPTI .

  • VMOVI .

  • VMOVP GICv4.0 .

  • VSYNC .

The GIC hardware determines whether the vPE is scheduled on a PE when:

  • GICR_VPENDBASER.Valid == 1.

  • GICR_VPENDBASER.Physical_Address holds the same value as defined in the VPT_addr field in the VMAPP GICv4.0 command for the vPE that is the target of the vLPI.

If, at the time that a vPE is descheduled from a PE, there are one or more vLPIs pending for the PE, GICR_VPENDBASER.PendingLast is set to 1. This can be used by the hypervisor to make scheduling decisions.

7.2.1 Doorbell interrupts

When an interrupt that targets a vPE is pending, it might target a vPE that is not currently scheduled on a PE. Where those interrupts are presented as physical interrupts, the hypervisor can schedule the vPE as a result of those interrupts. In this case, the hypervisor can make the scheduling decisions for the vPE based on the full set of pending virtual interrupts for the vPE.

The equivalent capability is provided in the case of direct injections of vLPIs by the provision of doorbell LPIs.

For a vLPI, the ITS can configure a physical LPI that is sent to a PE when the vLPI becomes pending and the vPE is not scheduled on that PE. This physical LPI is a Doorbell LPI.