Tuesday, June 26, 2007

Interrupt in Hypertransport Technology

Introduction

HT, unlike most legacy I/O bus implementations, does not define the use of interrupt pins, nor an interrupt controller. Instead, interrupt delivery is distributed to the HT devices themselves. Each device delivers interrupts by performing memory writes to memory address locations reserved for that purpose. The data written to these locations provides information that historically comes from or is handled by an interrupt controller (such as interrupt priority and vector information that specifies the location of the interrupt service routine). This method of interrupt delivery is commonly referred to as Message Signaled Interrupts.

HT supports message signaled interrupts via two message types:

  • Interrupt Request message — Interrupt requests are forwarded upstream as sized write transactions that target a reserved interrupt request address range. The host bridge receives these packets and based on the target address recognizes the transaction as an interrupt request. The specific actions taken by the bridge to process the interrupt request is platform-specific and not specified.

  • End of Interrupt message — HT also supports an End Of Interrupt (EOI) message that may be used by devices that require confirmation that their interrupt service routine has completed. These messages originate at the host and are forwarded downstream as a broadcast. Like the interrupt request message, the EOI request packet address must also fall within the reserved address range.


The address associated with the interrupt packets must include additional address bits to distinguish between the difference address ranges. If the Host Bridge is to resolve the address to within the specified interrupt address range (FD_0000_0000h to FD_F8FF_FFFFh), then Addr[31:24] must be included within the interrupt packets. Verification of the specification's intent can be found in the x86 compatibility definitions, which specify Addr[31:24] be delivered in the IntrInfo[31:24] field of the interrupt packet. To maintain compatibility with earlier versions of HT implementations, the specification sets a default value of F8h for IntrInfo[31:24].

For system platform implementations other than x86, the specification leaves open the possibility of the interrupt range being extended, but does not explicitly state that the interrupt range can be extended in the absence of the PIC IACK, System Management, and IO mappings. For example, some platforms may only need support for the interrupt and configuration packets. This would require the use of Addr[39:26], thereby permitting the Host Bridge to distinguish between the interrupt and configuration requests.

Interrupt Requests

Interrupt request messages originate within HT I/O devices and are sent upstream using the posted-write virtual channel. This assures that any posted write transactions that preceded the interrupt request are pushed ahead of it to memory before the host bridge receives the interrupt.

HT uses message-signaled interrupts that behave much like HT Sized Write (byte) transactions. The interrupt request packet format is defined, but how bit fields are used is implementation-specific

While interrupt information contained in a request varies with the implementation, basic content might include:

  • Type of interrupt

  • Target address or CPU ID of the recipient

  • Interrupting device's vector

  • Whether an End-Of- Interrupt (EOI) acknowledgement is required.

The specification defines a generic interrupt request packet format, thereby providing flexibility for supporting the interrupt protocols used in different platforms. For example:

  • An interrupt vector might be defined as 8 bits (e.g. x86 machines), while it may be 32 bits in other architectures.

  • Interrupt requests may come from devices attached directly to an HT link, and from devices residing on a legacy bus (e.g., PCI), where interrupt requests are gathered by an interrupt controller and delivered by a HT-to-PCI bridge to the HT bus and transported to the host.

  • Interrupt requests may all be directed to a single processor for handling, or particular interrupt requests may be directed to different processors in a multi-processor system. Etc.

Interrupt Request Packet


The interrupt request packet specifies a posted byte sized-write command with an address that falls within the reserved interrupt address range. The request packet is immediately followed by a single 4 byte data packet which carries interrupt information.

The End of Interrupt (EOI) Message

The HT specification defines the mechanism used to notify an interested party that an interrupt service routine has completed execution. The EOI is used to notify an Advanced Programmable Interrupt Controller (APIC) that an interrupt request has been processed. This is needed when more than one device is sharing the same interrupt line via level triggering. In such cases, the APIC needs confirmation that an interrupt has been serviced prior to sending another interrupt request. {See IA32 Processor Architecture book for more details.)

The EOI request is sent downstream through the HT fabric as a broadcast message that travels in the posted channel. Also, the EOI message targets the same reserved address ranges that interrupt requests use. When the broadcast EOI message reaches the end of a chain, it is simply dropped by the last device (no response is expected or sent because EOI travels in the posted channel)

Interrupt Discovery and Configuration Capability Block

Each function can have its own capability block, facilitating a mapping of interrupts to functions. The capability block not only defines the number of interrupts the function is designed to use, but also provides a way for system software to define the contents of the Interrupt Information fields that will be delivered to the host during each Interrupt Request.

No comments: