SYSTEM ARCHITECTURE

allowed to call the service procedures but not the kernel; service procedures can, however, call the kernel. Accordingly, the operating system has provided a gate for the service procedures; the privilege level of this gate is 3 so user code can call through it. By assigning the kernel gate privilege level I, the operating system permits the service procedures to call the kernel, but denies access to the user code, which is less-privileged than the kernel gate. Thus, an operating system can use gates to precisely define its entry points, including the privilege level required to use an entry point. In order to make system services callable from all tasks, operating systems nor- mally place their call gate(s) in the Global Descriptor Table.

To call through a trap gate, a task issues an Interrupt instruction; to call through a call gate, a task issues an ordinary intersegment Call instruction. Both instructions change the task's privilege level and change to the stack defined (in the task's TSS) for the higher privilege level. (The operating system must have its own stack in order to guarantee that it has enough stack space

tPERMITIEO CALL DR

~PROHIBITED CALL DR

INTERRUPT INSTRUCTION

0 INTERRUPT INSTRUCITDN

Figure 3-10. Gates as Protected Entry Points

to run; application tasks cannot safely be trusted to have left sufficient stack space.)

Before calling through a call gate, a task can push parameters on its stack as it would before calling another procedure. The 80386 auto- matically copies the parameters to the more- privileged stack (the Dword Count field in the call gate tells the 80386 how many dwords of parameters to copy). Systems that call through trap gates can pass parameters in registers.

3.6 Interrupts and Exceptions

Devices generate interrupts when they require attention, while instructions may incur exceptions when their execution encounters a special condi- tion, such as a not-present page. A typical interrupt or exception requires rapid invocation of a software handler that responds to the interrupt or exception. When the handler returns, the 80386 resumes execution of the instruction stream that was interrupted or incurred the exception. Because of their underlying similarity, the 80386 treats interrupts and exceptions in a unified manner.

Each interrupt source and each exception type has an identifying number in the range 0-255; the 80386 uses this number to invoke the handler associated with the interrupt or exception. Since exceptions are detected by the 80386, it defines the exception numbers shown in Table 3-1. Interrupt numbers are defined by the operating system. The operating system initializes an 8259A Programmable Interrupt Controller so that each interrupt source is associated with a number. When an interrupt occurs, the 8259A supplies the 80386 with the number of the interrupt. Interrupt instructions supply their numbers in their operands. Note that for compatibility with current and future Intel products, interrupti exception numbers 0-31 must not be used except as defined in Table 3-1. All other numbers may be used freely.

3-14

Page 39
Image 39
Intel 80386 manual Interrupts and Exceptions, Gates as Protected Entry Points