
Intel386
TM
DX MICROPROCESSOR
In Virtual 8086 Mode, a slightly different set of in-
structions are made IOPL-sensitive. The following in-
structions are IOPL-sensitive in Virtual 8086 Mode:
INT n;
PUSHF;
POPF;
STI;
CLI;
IRET
The PUSHF, POPF, and IRET instructions are IOPL-
sensitive in Virtual 8086 Mode only. This provision
allows the IF flag (interrupt enable flag) to be virtual-
ized to the Virtual 8086 Mode program. The INT n
software interrupt instruction is also IOPL-sensitive
in Virtual 8086 Mode. Note, however, that the INT 3
(opcode 0CCH), INTO, and BOUND instructions are
not IOPL-sensitive in Virtual 8086 mode (they aren’t
IOPL sensitive in Protected Mode either).
Note that the I/O instructions (IN, OUT, INS, OUTS,
REP INS, and REP OUTS) are
not
IOPL-sensitive in
Virtual 8086 mode. Rather, the I/O instructions be-
come automatically sensitive to the
I/O Permission
Bitmap
contained in the
Intel386 DX Task State
Segment
. The I/O Permission Bitmap, automatically
used by the Intel386 DX in Virtual 8086 Mode, is
illustrated by Figures 4.15a and 4-15b.
The I/O Permission Bitmap can be viewed as a 0–
64 Kbit bit string, which begins in memory at offset
BitDMapDOffset in the current TSS. BitDMapD
Offset must be
s
DFFFH so the entire bit map and
the byte FFH which follows the bit map are all at
offsets
s
FFFFH from the TSS base. The 16-bit
pointer BitDMapDOffset (15:0) is found in the word
beginning at offset 66H (102 decimal) from the TSS
base, as shown in Figure 4-15a.
Each bit in the I/O Permission Bitmap corresponds
to a single byte-wide I/O port, as illustrated in Figure
4-15a. If a bit is 0, I/O to the corresponding byte-
wide port can occur without generating an excep-
tion. Otherwise the I/O instruction causes an excep-
tion 13 fault. Since every byte-wide I/O port must be
protectable, all bits corresponding to a word-wide or
dword-wide port must be 0 for the word-wide or
dword-wide I/O to be permitted. If all the referenced
bits are 0, the I/O will be allowed. If any referenced
bits are 1, the attempted I/O will cause an exception
13 fault.
Due to the use of a pointer to the base of the I/O
Permission Bitmap, the bitmap may be located any-
where within the TSS, or may be ignored completely
by pointing the BitDMapDOffset (15:0) beyond the
limit of the TSS segment. In the same manner, only
a small portion of the 64K I/O space need have an
associated map bit, by adjusting the TSS limit to
truncate the bitmap. This eliminates the commitment
of 8K of memory when a complete bitmap is not
required, while allowing the fully general case if
desired.
EXAMPLE OF BITMAP FOR I/O PORTS 0–255:
Setting the TSS limit to
à
bitDMapDOffset
a
31
a
1
**
ó
[**
see note below
]
will allow a 32-byte bit-
map for the I/O ports
Y
0–255, plus a terminator
byte of all 1’s
[**
see note below
]
. This allows the
I/O bitmap to control I/O Permission to I/O port 0–
255 while causing an exception 13 fault on attempt-
ed I/O to any I/O port 80256 through 65,565.
**
IMPORTANT IMPLEMENTATION NOTE:
Beyond
the last byte of I/O mapping information in the I/O
Permission Bitmap
must
be a byte containing all 1’s.
The byte of all 1’s must be within the limit of the
Intel386 DX TSS segment (see Figure 4-15a).
4.6.5 Interrupt Handling
In order to fully support the emulation of an 8086
machine, interrupts in Virtual 8086 Mode are han-
dled in a unique fashion. When running in Virtual
Mode all interrupts and exceptions involve a privi-
lege change back to the host Intel386 DX operating
system. The Intel386 DX operating system deter-
mines if the interrupt comes from a Protected Mode
application or from a Virtual Mode program by exam-
ining the VM bit in the EFLAGS image stored on the
stack.
When a Virtual Mode program is interrupted and ex-
ecution passes to the interrupt routine at level 0, the
VM bit is cleared. However, the VM bit is still set in
the EFLAG image on the stack.
The Intel386 DX operating system in turn handles
the exception or interrupt and then returns control to
the 8086 program. The Intel386 DX operating sys-
tem may choose to let the 8086 operating system
handle the interrupt or it may emulate the function of
the interrupt handler. For example, many 8086 oper-
ating system calls are accessed by PUSHing param-
eters on the stack, and then executing an INT n in-
struction. If the IOPL is set to 0 then all INT n instruc-
tions will be intercepted by the Intel386 DX Micro-
processor operating system. The Intel386 DX oper-
ating system could emulate the 8086 operating sys-
tem’s call. Figure 4-25 shows how the Intel386 DX
operating system could intercept an 8086 operating
system’s call to ‘‘Open a File’’.
An Intel386 DX operating system can provide a Vir-
tual 8086 Environment which is totally transparent to
the application software via intercepting and then
emulating 8086 operating system’s calls, and inter-
cepting IN and OUT instructions.
58