HyperTransportв„ў System Architecture

2017-07-07 02:10:07

The HT specification defines the mechanism necessary to support x86 compatible interrupt handling. This mechanism supports both single and multiprocessor interrupt handling:

Cascaded PIC (8259) Interrupt controllers for legacy support with single processor systems.

APIC support for x86 multiprocessor systems.

The APIC solution includes support for delivering 8259 interrupt requests to a single processor, and HT takes advantage of this support for delivering interrupt requests in single processor platforms. Therefore, the HT method of supporting APIC interrupt controllers is discussed first, followed by a discussion of 8259 support.

APIC Interrupt Support

The APIC subsystem was designed to support multi-processing implementations . The subsystem permits an interrupt to be directed to a particular processor for handling or may deliver an interrupt to a group of processors and allow them to arbitrate to determine which one will accept and service the interrupt. In addition to standard interrupt delivery, the APIC bus supports delivery of other interrupts including 8259 interrupts, NMI (Non Maskable Interrupts), and SMI# (x86 System Management Interrupts).

Legacy Method of Handling APIC Interrupts

Figure 22-3 on page 495 illustrates a standard APIC subsystem implemented in a legacy-based system with a PCI-X expansion bus. The APIC subsystem is split between the IO APIC located in the ICH and local APIC modules associated with each CPU. A synchronous APIC bus connects the IO APIC with the local APIC modules of all processors.

Figure 22-3. Legacy APIC Implementation

Interrupts are send via the APIC bus to one or more processors. The destination of the interrupt and the type of interrupt being sent (Delivery Mode) is a function of how the Interrupt Redirection Register within the IO APIC is programmed by software. Each input pin to the IO APIC has an associated Interrupt Redirection Register that specifies how interrupts received on that pin will be handled. The name for this register comes from its primary job of directing each interrupt to a specific entry in the interrupt table. The table entry contains the memory address of the interrupt service routine handler associated with the interrupt input. Figure 22-4 on page 497 illustrates the redirection function along with the format of each register. A look at each field clarifies how the IO APIC knows the type of interrupt to send, its destination, and the entry point of the interrupt handler.

Vector ” points to an entry in the x86 interrupt vector table containing the entry point of the interrupt service routine.

Delivery Mode ” Defines the type of interrupt being signalled.

DM (Destination Mode) ” Specifies the number of bits in the destination field that identifies the target processor(s).

Interrupt Status ” Specifies that an interrupt has been sent but delivery is being delayed due to the APIC bus busy condition, or because the local APIC being targeted is temporarily unable to accept the interrupt.

Polarity ” Specifies whether an interrupt input is active high or low.

Remote IRR (Interrupt Request Register) ” Supports level triggered sharable interrupts and has no meaning for edge triggered interrupts. This bit and the EOI message together tell the I/O APIC when an interrupt for this pin has been serviced; thus, if the input pin is still active (low) another interrupt is pending and can be signaled. This bit is reset (0) when an EOI message is received from a local APIC and set (1) when Local APIC(s) accept the level interrupt sent by the I/O APIC.

Trigger Mode ” Determines whether the interrupt input is edge or level triggered.

Mask ” Inhibits the transfer of interrupts associated with this pin.

Destination ” Specifies the target processor(s) with an APIC ID value. The number of bits used depends on the destination mode selected. The lower nibble of this field is used for static destination mode, while the entire 8-bit field is used for logical destination mode.

Figure 22-4. Format of the Interrupt Redirection Register

For a review of APIC operation, refer to MindShare's Pentium Processor System Architecture and Pentium Pro and Pentium 3 System Architecture (www. mindshare .com).

HT Method of Handling APIC Interrupts

HT replaces the APIC bus by sending interrupts via the SM interrupt message. An actual APIC is typically implemented in an x86-based multiprocessor platform as illustrated in Figure 22-5. In this example, the HT bus provides the interconnect between the Host Bridge and I/O Controller Hub (ICH). The IO APIC receives interrupt requests from PCI-X devices and from imbedded I/O devices within the ICH. The IO APIC in turn delivers interrupt requests to the SMC for transfer to the target processor(s) via the Host Bridge and APIC bus.

Figure 22-5. HT-Based Platform with IO APIC

HT I/O Device Delivery of X86 Interrupts

HT I/O devices may also need to signal interrupts, and must use the message signaled interrupt method of delivery. To signal an interrupt request, HT I/O devices must issue an SM interrupt message directly. The interrupt message sent by an HT device contains the APIC-compliant information. Note that HT I/O installed in x86 platforms are required to use the APIC definition when sending interrupt request messages whether an IO APIC is implemented within the system or not. Figure 22-6 illustrates a system in which SM interrupt requests will be issued HT I/O devices and by the SMC (in response to IO APIC interrupt requests).

Figure 22-6. Example X86 Platform Containing HT I/O Devices and an IO APIC

Figure 22-7 on page 502 illustrates the format of the x86 SM interrupt message that contains APIC-compliant data. Software must set up the redirection registers associated with each APIC input pin to define the characteristics of the interrupt. Similarly, each x86-compatible HT device must emulate a redirection register for each interrupt it supports. This is accomplished through the interrupt definition registers. (See "Interrupt Definition Registers" on page 211.) The content of the x86-compatible SM interrupt message comes from the interrupt definition register.

Figure 22-7. Format of X86-Based Interrupt Request Message

The portion of the message that is APIC-specific include:

MT[3:0] ” Message type indicates the type of interrupt being delivered. This field represents the Delivery Mode specified by the APIC definition. The HT specified values include:
- Arbitrated - Used to deliver an interrupt to two or more processors that will arbitrate between themselves to determine which is currently executing the lowest priority code. That processor will accept and service the interrupt. These interrupts can be either edge or level triggered.
- Fixed - This interrupt targets the processor(s) specified in the destination field. It can target a single processor, a group of processors, or can be broadcast to all processors. These interrupts can be either edge or level triggered.
- SMI - Specifies that a System Management Interrupt is being delivered by an HT device. No interrupt vector is specified for SMIs. These interrupts must use edge triggering.
- NMI - Non-Maskable Interrupts are typically sent by devices that have incurred fatal (non-recoverable) errors. These interrupts must also use edge triggering.
- INIT - The Initialize delivery type goes to all processor cores listed in the destination. All addressed local APICs will transition to their INIT state. INIT is always treated as an edge triggered interrupt.
- ExtInt - External Interrupt delivery indicates that an interrupt request has been received by a legacy 8259 interrupt controller. Consequently, no vector is associated with the interrupt. The processor must perform and Interrupt Acknowledge special cycle upon receiving this interrupt.

DM ” Destination Mode, same as defined by APIC, physical or logical. The mode defines the number of bits within the destination field that will be used.

RQEOI ” Request EOI indicates whether an EOI message is required to clear the interrupt and is comparable to the Remote IRR field defined by the APIC.

Interrupt Destination ” Specifies the processor(s) targeted by the interrupt. The number of bits used depends on the Destination Mode.
- Physical destination uses bits [7:0]. A value of FFh selects all processors. Note that some x86 platforms use only bit [3:0] as the physical ID.
- Logical destination uses all 32 bits of the destination field. However, some x86 implementations are restricted to [7:0] for the logical ID.

Table 22-1 taken from the specification summarizes each interrupt message type and lists the permissible values for the other APIC- related fields.

Table 22-1. Summary of Interrupt Request Bit Field Encoding Values

MT[3:0]	Name	RQEOI	Vector	DM	Destination
0_000	Fixed	0 or 1	0-FFh		0-FF
	Fixed			1	0-FFFF_FFFFh
0_001	Arbitrated				0-FF
	Arbitrated			1	0-FFFF_FFFFh
0_010	SMI				FFh
0_011	NMI
0_100	INIT
0_101	Startup (Host Only)
0_110	ExtInt				FFh
1_011	Legacy NMI (LINT1) ^[*]
1_110	Legacy PIC ExtInt (LINT0) ^[*]
x_111	Reserved for EOI

^[*] The Legacy NMI and PIC delivery is typically related to a single processor implementation as discussed in the respective sections entitled, "Legacy NMI Signaling" on page 508 and "Legacy Interrupts (8259 Interrupt Controllers)" on page 503.

EOI ( End of Interrupt) Message

When an HT device (I/O device or ICH /South bridge) sends an interrupt request that requires confirmation of interrupt service completion, it must set the RQEOI bit in the interrupt request message. Subsequently, the interrupt service routine clears the EOI bit within the local APIC and the local APIC returns an EOI message back to the Host Bridge. The bridge then initiates an SM EOI message that is broadcast to all HT devices downstream. Figure 22-8 on page 503 illustrated the format of the EOI message.

Figure 22-8. EOI Request Message Format

Legacy Interrupts (8259 Interrupt Controllers)

Many x86 systems employ a single processor and use a cascaded pair of 8259 interrupt controllers for managing interrupts. This section briefly describes the legacy method of handling these interrupts for background information, and details the HT method for providing compatibility.

The Legacy Method of Handling 8259 Interrupts

Figure 22-9 on page 504 illustrates a single x86 processor system with a cascaded pair of 8259 interrupt controllers. Note that the Interrupt Request (INTR) signal connects directly between the ICH/South bridge and the processor. The sequence of events associated with signaling and servicing an interrupt delivered by the 8259 interrupt controller is enumerated below:

The 8259 Interrupt controllers signal an interrupt request (INTR) to the processor upon receiving an interrupt request from an I/O device.

The processor detects the INTR, but has no knowledge of which interrupt routine to execute. To obtain this information the processor performs an interrupt acknowledge special cycle to read the interrupt vector from the interrupt controllers.

The Host Bridge detects the interrupt acknowledge special cycle and forwards it to the HT device that contains the 8259 interrupt controllers (typically the ICH/South bridge).

The interrupt controller (via the ICH/South bridge) returns the vector number associated with the highest priority interrupt pending.

The Host Bridge receives the vector and forwards it on to the processor.

Having retrieved the interrupt vector, the processor fetches and executes the interrupt service routine corresponding to the vector and interrupting device.

Figure 22-9. Legacy x86 Platform ” Single Processor & 8259 Interrupt Controllers

HT Method of Handling 8259 Interrupts

Figure 22-10 on page 505 illustrates a single processor HT system that employs a cascaded pair of 8259 interrupt controllers. The sequence of events described in the previous section are the same for the HT system with two differences:

The ICH delivers INTR as a virtual wire via an SM Interrupt Message.

The Host Bridge delivers the interrupt acknowledge special cycle by performing a memory read from the address space reserved for interrupt acknowledge transactions.

Figure 22-10. HT-based System with 8259s

Signaling INTR

The SMC routes interrupt request from the 8259s to the Host Bridge via an SM Interrupt Request message. This message acts as a virtual wire for signaling INTR from the ICH to the Host Bridge, which signals INTR to the CPU. Figure 22-11 on page 506 illustrates the interrupt request packet. The SM Interrupt Request message defines the ExtInt (external interrupt) type for delivering interrupts that originate at the 8259 interrupt controller. Note that two methods of delivering the ExtInt type are defined:

MT[3:0] = 0_110 ” Notifies the processor of the interrupt request via the APIC bus. This method requires that the APIC bus be enabled to accept interrupts. This approach is normally supported only by multiprocessor-based platforms and operating systems.

MT[3:0] = 1_110 ” Notifies the processor of the interrupt request via its INTR input. This is the legacy method of interrupt delivery to the processor that is used by single processor-based platforms and operating systems.

Figure 22-11. Legacy INTR ” Interrupt Request and Data Packet Format

In both cases, processors must obtain the interrupt vector from the 8259 interrupt controllers by performing interrupt acknowledge transactions.

Signaling Interrupt Acknowledge

Once an x86 CPU recognizes an INTR, it performs an Interrupt Acknowledge cycle to obtain the interrupt vector from the interrupt controller. When the Host Bridge receives the interrupt acknowledge special cycle, it forwards the special cycle to the HT bus in the form of a Sized byte read with a target address that falls within the reserved Interrupt Acknowledge address range (a 1MB range from FD_F900_0000 to FD_F90F_FFFF). The device containing the interrupt controller (typically the ICH/South bridge) returns a read response packet containing an 8-bit vector value. The Host bridge recognized the Interrupt Acknowledge response and forwards the vector on to the processor. Figure 22-12 illustrates the HT Interrupt Acknowledge Request packet.

Figure 22-12. Interrupt Acknowledge Request Packet Format

8259 EOI Command

End of Interrupt for the 8259 interrupt controllers is performed via I/O writes to the legacy address locations:

I/O write to location 20h (Master Interrupt Controller)

I/O write to location A0h (Slave Interrupt Controller)

These I/O writes are encoded into the HT address space that is reserved for I/O transactions. Translation of the HT address to I/O addresses is discussed in Chapter 21, entitled "Address Remapping," on page 477.

The HT-defined EOI message is reserved for the APIC EOI and not used for the legacy 8259 interrupt controllers.

Legacy NMI Signaling

Figure 22-9 on page 504 illustrates the legacy Non-Maskable Interrupt (NMI) signaling between the ICH/South bridge and the CPU. When the processor recognizes the NMI, it knows that the NMI handler is stored within entry 2 of the interrupt table.

HT delivers NMOS to the processor via the SM interrupt request message as expected. The message types are defined for delivering an NMI to the processor:

MT[3:0] = 0_011 ” Notifies the processor of the NMI via the APIC bus. This method requires that the APIC bus be enabled to accept interrupts. This approach is normally supported only by multiprocessor-based platforms and operating systems.

MT[3:0] = 1_011 ” Notifies the processor of the NMI via its NMI signal input. This is the legacy method of NMI delivery to the processor, and is used by single processor-based platforms and operating systems.

Figure 22-10 on page 505 illustrates the delivery of the SM NMI message from the ICH to the Host Bridge, and the Host Bridge signaling NMI directly to the CPU.