20-10 Vol. 3B

8086 EMULATION

exception or hardware interrupt through the protected-mode IDT (normally through an interrupt or trap gate) 
and the protected-mode exception- and interrupt-handlers. The processor may handle the exception or 
interrupt within the context of the virtual 8086 task and return to virtual-8086 mode on a return from the 
handler procedure. The processor may also execute a task switch and handle the exception or interrupt in the 
context of another task.

•

The processor services a software interrupt generated by code executing in the virtual-8086 task (such as a 
software interrupt to call a MS-DOS* operating system routine). The processor provides several methods of 
handling these software interrupts, which are discussed in detail in Section 20.3.3, “Class 3—Software 
Interrupt Handling in Virtual-8086 Mode”. Most of them involve the processor entering protected mode, often 
by means of a general-protection (#GP) exception. In protected mode, the processor can send the interrupt to 
the virtual-8086 monitor for handling and/or redirect the interrupt back to the application program running in 
virtual-8086 mode task for handling.
IA-32 processors that incorporate the virtual mode extension (enabled with the VME flag in control register 
CR4) are capable of redirecting software-generated interrupts back to the program’s interrupt handlers without 
leaving virtual-8086 mode. See Section 20.3.3.4, “Method 5: Software Interrupt Handling”, for more 
information on this mechanism.

•

A hardware reset initiated by asserting the RESET or INIT pin is a special kind of interrupt. When a RESET or 
INIT is signaled while the processor is in virtual-8086 mode, the processor leaves virtual-8086 mode and enters 
real-address mode.

•

Execution of the HLT instruction in virtual-8086 mode will cause a general-protection (GP#) fault, which the 
protected-mode handler generally sends to the virtual-8086 monitor. The virtual-8086 monitor then 
determines the correct execution sequence after verifying that it was entered as a result of a HLT execution.

See Section 20.3, “Interrupt and Exception Handling in Virtual-8086 Mode”, for information on leaving virtual-8086 
mode to handle an interrupt or exception generated in virtual-8086 mode.

20.2.7 Sensitive 

Instructions

When an IA-32 processor is running in virtual-8086 mode, the CLI, STI, PUSHF, POPF, INT n, and IRET instructions 
are sensitive to IOPL. The IN, INS, OUT, and OUTS instructions, which are sensitive to IOPL in protected mode, are 
not sensitive in virtual-8086 mode.
The CPL is always 3 while running in virtual-8086 mode; if the IOPL is less than 3, an attempt to use the IOPL-
sensitive instructions listed above triggers a general-protection exception (#GP). These instructions are sensitive 
to IOPL to give the virtual-8086 monitor a chance to emulate the facilities they affect.

20.2.8 

Virtual-8086 Mode I/O

Many 8086 programs written for non-multitasking systems directly access I/O ports. This practice may cause prob-
lems in a multitasking environment. If more than one program accesses the same port, they may interfere with 
each other. Most multitasking systems require application programs to access I/O ports through the operating 
system. This results in simplified, centralized control.
The processor provides I/O protection for creating I/O that is compatible with the environment and transparent to 
8086 programs. Designers may take any of several possible approaches to protecting I/O ports:

•

Protect the I/O address space and generate exceptions for all attempts to perform I/O directly.

•

Let the 8086 program perform I/O directly.

•

Generate exceptions on attempts to access specific I/O ports.

•

Generate exceptions on attempts to access specific memory-mapped I/O ports.

The method of controlling access to I/O ports depends upon whether they are I/O-port mapped or memory 
mapped.