Interrupt 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. Figure 8-4 on page 205 illustrates the format of the interrupt request packet.

Figure 8-4. Format of Interrupt Request Packet

graphics/08fig04.jpg

The specification requires specific values in some fields within the interrupt request packet:

  • Command Type (Cmd) ” This field must specify a posted, byte, sized write packet with a value of 101000b.

  • Count [3:0] ” The count field must contain a value of zero to specify that the data packet size is 4 bytes. There is no "byte mask"; instead, the single dword contains additional interrupt information.

  • Interrupt Information [31:2] ” The interrupt information fields within the request packet are defined for interrupt-specific information as required by a given platform. The specification defines the contents of these fields for x86-based platforms only. The following Interrupt info fields have optional definitions:

    • Interrupt Type (IntrInfo [4:2]) ” This 3-bit field defines the type of interrupt request. All values except 111b are defined as implementation specific. The only definition provided by the specification (111b) defines the interrupt packet as an EOI packet (See "EOI Packet Format" on page 208). Refer to "HT Method of Handling APIC Interrupts" on page 498 for examples of other message types (NMI, SMI, etc.) used in x86-based platforms.

    • Request EOI (IntrInfo [5]) ” This bit is set by an HT device to request that an EOI request packet be returned after the interrupt service has finished.

    • IntrInfo [31:8] ” The specification states that contents of these bit location during the request "will be retuned in the EOI message, although some hosts may not support use of all bits."

    • IntrInfo[31:24] ” Note that byte 6 of Figure 8-4 is defined as Addr[31:24] that has a default value of F8h, rather than simply IntrInfo[31:24]. See Addr description below.

  • Addr[39:24] ” This address represents the upper address bits (FD_F8xx_xxxxh) of the reserved interrupt address range. This address permits the Host Controller to differentiate interrupt packets from the other reserved packet types. (See "The Interrupt Message Address Range" on page 201.) Additional address lines may be required depending on the platform implementation. Also see "X86 Interrupt Support" on page 494 for definition of the address field in x86 platforms.

Interrupt Request Data Packet

Figure 8-5, illustrates the 4-byte data packet, which is concatenated directly to the end of the Interrupt Request packet. The data packet fields are defined as:

  • IntrInfo [55:32] = The upper 24 bits of interrupt information are defined as platform-specific. Figure 22-7 on page 502 defines these fields for x86 platforms.

  • Reserved ” The last byte of the data packet is reserved.

Figure 8-5. Format of the Interrupt Request Data Packet

graphics/08fig05.jpg

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)

EOI Packet Format

The EOI packet (Figure 8-6 on page 209) is structured like other broadcast message requests. The specification defines the use or behavior of some fields within the EOI packet, as described below:

  • Command Type (Cmd) ” This field must specify a posted, broadcast packet with a value of 111010b.

  • Interrupt Type (IntrInfo [4:2]) ” This 3-bit field defines the type of interrupt request. The specification defines a value of 111b, identifying the packet as EOI.

  • IntrInfo [31:08] = These fields are duplicated from the corresponding interrupt request packet. Other requirements may also exist as discussed below:

    • IntrInfo[15:08] may optionally also be 00h and used as a "wild card" that can match any value of IntrInfo[15:08].

    • IntrInfo[31:24] ” Note that byte 6 of Figure 8-6 on page 209 is defined as Addr[31:26]. See Addr description below for additional information.

  • Addr[39:32] ” This address represents the upper address bits of the reserved interrupt address range (FD_0000_0000 to FD_F800_0000h). This address permits the Host Controller to differentiate interrupt packets from the other reserved packet types. (See "The Interrupt Message Address Range" on page 201. for more detail.) Additional address lines may be required depending on the platform implementation.

Figure 8-6. EOI Packet Format

graphics/08fig06.gif



HyperTransport System Architecture
HyperTransportв„ў System Architecture
ISBN: 0321168453
EAN: 2147483647
Year: 2003
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net