Generic Interrupt Controller versions 3 and 4: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
VisualWikitext
(ARM MSI IRQ support)
Line 11: Line 11:


= Message-Based IRQ support =
= Message-Based IRQ support =

⚫
The ITS is one method of supporting MSI IRQs on ARM platforms that implement the GIC architecture. There are two approaches, and a platform must support '''only one''' (GICv3&4 specification, section 6.2):
⚫
* The device generates an LPI by writing directly to the Redistributor's GICR_SETLPIR.
⚫
* The device generates an LPI via the ITS service, which will generate the LPI on its behalf.


== Locality-based Peripheral IRQ ==
== Locality-based Peripheral IRQ ==

Support for a new type of IRQ is added from GICv3 onwards: Locality-based Peripheral IRQs (LPIs), which are used for message-based IRQs.


== Interrupt Translation Service ==
== Interrupt Translation Service ==


Note that the configuration of ITS should have no effect on SPIs, SGI, PPIs (GICv3&4 specification, section 6.2: "An ITS has no effect on SGIs, SPIs or PPIs."). Its purpose is confined to generating IRQ signals from in-band bus messages.
⚫
The ITS is one method of supporting MSI IRQs on ARM platforms that implement the GIC architecture. There are two approaches, and a platform must support '''only one''' (GICv3&4 specification, section 6.2):
⚫
* The device generates an LPI by writing directly to the Redistributor's GICR_SETLPIR.
⚫
* The device generates an LPI via the ITS service, which will generate the LPI on its behalf.


For the GIC architecture, ARM devices that support MSI (message-signaled IRQs) are each assigned a DeviceID. Additionally, each MSI IRQ that the device will generate is assigned an EventID. This combination of DeviceID+EventID are used as inputs to the ITS. The ITS then uses the DeviceID to index into its Device Table, and select that device's Interrupt Translation Table (ITT). The EventID is then used to index into the ITS' ITT for that device, and select the pertinent Interrupt Translation Entry (ITE).
For the GIC architecture, ARM devices that support MSI (message-signaled IRQs) are each assigned a DeviceID. Additionally, each MSI IRQ that the device will generate is assigned an EventID. This combination of DeviceID+EventID are used as inputs to the ITS. The ITS then uses the DeviceID to index into its Device Table, and select that device's Interrupt Translation Table (ITT). The EventID is then used to index into the ITS' ITT for that device, and select the pertinent Interrupt Translation Entry (ITE).


Each ITE then indicates a Collection Table (CT) entry, which gives the target Redistributor for a physical MSI IRQ. For GIVc3, if a device has a physical MSI IRQ, and the OS Hypervisor would like to virtualize that IRQ to a Guest VM, the hypervisor must deliver that IRQ as a standard virtual IRQ (Not 100% sure on this yet).
Each ITE has information about the target Redistributor (and therefore the target PE) for the IRQ.

GICv4 also adds support for delivering virtual MSI IRQs. In this case, the ITE indicates a vPEID, which indicates a vPE table entry (and therefore, the physical Redistributor that hosts the target vPE for the virtual MSI).


= References =
= References =

Revision as of 01:19, 3 January 2017

Introduction

This page seeks to give a quick reference to the behaviour of the version 3 and 4 GIC, especially relative to version 2. It heavily references [User:Gravaera/Generic Interrrupt Controller], and recommends that page as prior reading.

Version difference summary

Differences between GICv2 and GICv3

Differences between GICv3 and GICv4

Redistributors

Message-Based IRQ support

The ITS is one method of supporting MSI IRQs on ARM platforms that implement the GIC architecture. There are two approaches, and a platform must support only one (GICv3&4 specification, section 6.2):

  • The device generates an LPI by writing directly to the Redistributor's GICR_SETLPIR.
  • The device generates an LPI via the ITS service, which will generate the LPI on its behalf.

Locality-based Peripheral IRQ

Support for a new type of IRQ is added from GICv3 onwards: Locality-based Peripheral IRQs (LPIs), which are used for message-based IRQs.

Interrupt Translation Service

Note that the configuration of ITS should have no effect on SPIs, SGI, PPIs (GICv3&4 specification, section 6.2: "An ITS has no effect on SGIs, SPIs or PPIs."). Its purpose is confined to generating IRQ signals from in-band bus messages.

For the GIC architecture, ARM devices that support MSI (message-signaled IRQs) are each assigned a DeviceID. Additionally, each MSI IRQ that the device will generate is assigned an EventID. This combination of DeviceID+EventID are used as inputs to the ITS. The ITS then uses the DeviceID to index into its Device Table, and select that device's Interrupt Translation Table (ITT). The EventID is then used to index into the ITS' ITT for that device, and select the pertinent Interrupt Translation Entry (ITE).

Each ITE then indicates a Collection Table (CT) entry, which gives the target Redistributor for a physical MSI IRQ. For GIVc3, if a device has a physical MSI IRQ, and the OS Hypervisor would like to virtualize that IRQ to a Guest VM, the hypervisor must deliver that IRQ as a standard virtual IRQ (Not 100% sure on this yet).

GICv4 also adds support for delivering virtual MSI IRQs. In this case, the ITE indicates a vPEID, which indicates a vPE table entry (and therefore, the physical Redistributor that hosts the target vPE for the virtual MSI).

References

Retrieved from "https://osdev.wiki/wiki/Generic_Interrupt_Controller_versions_3_and_4?oldid=5439"