AP-578
2/21/97 12:57 PM 24329102.DOC
INTEL CONFIDENTIAL
(until publication date)
It may at first glance seem that there is a possibility
of FP exceptions being lost because of exceptions
that are discarded during state swaps. This is not
the case, as the exception will be re-issued when
the FP state is reloaded. Walking through state
swaps both with and without pending numeric
exceptions will clarify the operation of these two
handlers.
Case 1: FPU State Swap Without Numeric
Exception
Assume two threads ‘A’ and ‘B’, both using the
floating-point unit. Let A be the thread to have most
recently executed a FP instruction, with no pending
numeric exceptions. Let B be the currently
executing thread. CR0.TS was set when thread A
was suspended. When B starts to execute a FP
instruction the instruction will fault with the DNA
exception because TS is set.
At this point the handler is entered, and eventually it
finds that the current FPU Owner is not the
currently executing thread. To guard the FPU state
swap from extraneous numeric exceptions, the FPU
Owner is set to be the kernel. The old owner’s FPU
state is saved with FNSAVE, and the current
thread’s FPU state is restored with FRSTOR.
Before exiting, the FPU owner is set to thread B,
and the TS bit is cleared.
On exit, thread B resumes execution of the faulting
FP instruction and continues.
Case 2: FPU State Swap with Discarded
Numeric Exception
Again, assume two threads ‘A’ and ‘B’, both using
the floating-point unit. Let A be the thread to have
most recently executed a FP instruction, but this
time let there be a pending numeric exception. Let
B be the currently executing thread. When B starts
to execute a FP instruction the instruction will fault
with the DNA exception and enter the DNA handler.
(If both numeric and DNA exceptions are pending,
the DNA exception takes precedence, in order to
support handling the numeric exception in its own
context.)
When the FNSAVE starts, it will trigger an interrupt
via FERR# because of the pending numeric
exception. After some system dependent delay, the
numeric exception handler is entered. It may be
entered before the FNSAVE starts to execute, or it
may be entered shortly after execution of the
FNSAVE. Since the FPU
Owner is the kernel, the numeric exception handler
simply exits, discarding the exception. The DNA
handler resumes execution, completing the
FNSAVE of the old FP context of thread A and the
FRSTOR of the FP context for thread B.
Thread A eventually gets an opportunity to handle
the exception that was discarded during the task
switch. After some time, thread B is suspended,
and thread A resumes execution. When thread A
starts to execute an FP instruction, once again the
DNA exception handler is entered. B’s FPU state is
FNSAVE’ed, and A’s FPU state is FRSTOR’ed.
Note that in restoring the FPU state from A’s save
area, the pending numeric exception flags are
reloaded in to the FP status word. Now when the
DNA exception handler returns, thread A resumes
execution of the faulting FP instruction just long
enough to immediately generate a numeric
exception, which now gets handled in the normal
way. The net result is that the task switch and
resulting FPU state swap via the DNA exception
handler causes an ‘extra’ numeric exception which
can be safely discarded.
3.6.4 INTERRUPT ROUTING FROM THE
KERNEL
In MS-DOS, an application that wishes to handle
numeric exceptions hooks interrupt 2 by placing its
handler address in the interrupt vector table, and
exiting via a jump to the previous interrupt 2
handler. Protected mode systems that run MS-DOS
programs under a subsystem can emulate this
exception delivery mechanism. For example,
assume a protected mode O.S. that runs with
CR.NE = 1, and that runs MS-DOS programs in a
virtual machine subsystem. The MS-DOS program
is set up in a virtual machine that provides a
virtualized interrupt table. The MS-DOS application
hooks interrupt 2 in the virtual machine in the
normal way. A numeric exception will trap to the
kernel via the real INT 16 residing in the kernel at
ring 0. The INT 16 handler in the kernel then
locates the correct MS-DOS virtual machine, and
reflects the interrupt to the virtual machine monitor.
The virtual machine monitor then emulates an
interrupt by jumping through the address in the
virtualized interrupt table, eventually reaching the
application’s numeric exception handler.
To Next Page
Loading...