Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS VOLUME 3 REV 2.3, Руководство пользователя, Страница: 792 / 1898

2:544 Volume 2, Part 2: Interruptions and Serialization
A typical lightweight interruption handler can operate completely out of register bank 0.
If the bank 0 registers provide sufficient storage for the handler, none of the interrupted
context’s register state need be saved to memory, and the handler does not need to
use stacked registers. Assuming no stacked registers are needed, the lightweight
interruption handler can operate with an incomplete current register stack frame,
obviating the need for
cover
and
alloc
instructions in the handler. This also allows the
TLB related handlers to service TLB misses that result from mandatory RSE loads to the
current frame.
3.4.2 Heavyweight Interruptions
Heavyweight interruption handlers are allocated only 256 bytes (48 instructions) per
handler in the IVT. This stub provides enough space to save minimal processor state,
re-enable interruption collection and external interrupts, and branch to another routine
to handle the interruption. Unlike a lightweight interruption handlers described above,
heavyweight interruption handlers use general register bank 0 only until they can
establish a safe memory context for spilling the interrupted context’s state. This allows
heavyweight handlers to be interruptible and to take exceptions.
A heavyweight handler stub (i.e. the portion of the handler that is located in the IVT)
should determine exactly which type of interruption has occurred based on its offset in
the IVT and the contents of the ISR control register. It can then branch out of the IVT to
the actual interruption handler. For some heavyweight interruptions (e.g. Data Debug
fault), these handlers are typically written in a high-level programming language; for
others (e.g. emulation handlers) the interruption can be handled efficiently in Itanium
architecture-based assembly code.
The sequence given below illustrates the steps that an Itanium architecture-based
heavyweight handler needs to perform to save the interrupted context’s state to
memory and to create an interruptible execution environment. These steps assume
that the low-level kernel code, the kernel backing store, and the kernel memory stack
are pinned in the TLB (using a translation register), so that no TLB misses arise from
referencing those memory pages. The ordering of the steps below is approximate and
other operating system strategies are possible.
1. Copy the interruption resources (IIP, IPSR, IIPA, ISR, IFA, IIB0-1) into bank 0 of
the banked registers. To avoid conflicts with processor firmware, use registers
GR24-31 for this purpose. Both register bank 0 and the interruption control
registers are accessible, since, as described in
Section 3.3.1 , the processor
hardware, upon an interruption always switches to register bank 0, and clears
PSR.ic and PSR.i.
2. Preserve the interrupted the predicate registers into bank 0 of the banked
registers.
3. Determine whether interruption occurred in the operating system kernel or in
user space by inspecting both IPSR.cpl and the memory stack pointer (GR12).
a. If IPSR.cpl is zero and the interrupted context was already executing on a
kernel stack, then no memory stack switch is required.
b. Otherwise, software needs to switch to a kernel memory stack by preserving
the interrupted memory stack pointer to a banked register in bank 0, and
setting up a new kernel memory stack pointer in GR12.