Article View: comp.os.msdos.programmer
Article #7654V86 Mode, IOPL = 3, INT/IRET: What really happens???
From: Gary A. Hildebrand
Date: Fri, 22 Jan 1993 00:03
Date: Fri, 22 Jan 1993 00:03
69 lines
3932 bytes
3932 bytes
All,
The sections for Virtual 8086 mode in the Intel 386/486DX programmer's
reference manuals talk about how the INT and IRET instructions can be
protected from execution when in V86 mode, by setting an IOPL of less than
3. Since V86 mode runs with an effective CPL of 3, an attempt to execute
either of these instructions (and a few others which could manipulate the
interrupt flag) will result in a General Protection exception (the infamous
exception 13). But what really happens when the IOPL *is* 3?
I can imagine two scenarios for the case of INT:
1. It works just like a hardware interrupt or CPU exception in V86
mode, chaining through the protected mode IDT, the handler for which
might then have to distinguish between software interrupts and other
cases before taking action
2. It works just like a software interrupt in 386/486 real mode,
chaining through the 8086 interrupt table (now that I think of it
probably unlikely, since even in real mode the IDTR determines the
base and limit of the 8086 interrupt table, unlike a real 8086/8, and
the IDTR would already be pointing to a protected mode IDT for the
benefit of V86 mode)
Even though the second scenario might be better than the first for some
cases, the first is still highly reasonable and if not desired, then just
set IOPL less than 3 and completely emulate what you want. But more
importantly, what about the case for IRET? The pseudocode for the
instruction in the Intel documentation just shows the generation of a
General Protection exception when V86 mode is active, which would indicate
the value of IOPL doesn't matter. This can't be right. So again, I can
imagine two scenarios:
1. It's sort of like an IRET in protected mode, but not exactly,
since one cannot expect saved values of all the segment registers or
even a 32-bit IP to be on the stack, which will be a priveledge level
3 stack anyway.
2. It works just like an IRET in 386/486 real mode, popping IP,
CS, and FLAGS off the stack to resume execution at the interrupted
procedure.
So will IOPL=3 really work for V86 mode? If the second scenario for IRET
was what happened, then the following method could be used for reflecting
an arbitrary software interrupt to real mode:
1. Depending on how INT's are interpreted, either the exception
handler in the V86 monitor performs an IRET to the real-mode code
pointed to by the 8086 interrupt table at address 0, or that happens
automatically care of the CPU.
2. When the real-mode interrupt handler exits with IRET, values on its
stack saved by the V86 monitor handler or CPU allow it to return
straight to the original calling procedure.
If IRET acts any differently, probably both the interrupt and return would
need to be emulated using IOPL<3, which complicates things somewhat.
Any protected mode programming gurus want to tackle this one? I'm all
ears (actually eyes :-)!
Thanks in advance,
Gary
--
/ Gary A. Hildebrand Internet: gah@mew.mei.co.jp \
/ Matsushita Electric Works, Ltd. UUCP: uunet!mew.mei.co.jp!gah \
/ 13-2, Mita 5-chome, Minato-ku Fax: 03-3451-0793 \
/ Tokyo 108, JAPAN Tel: 03-3452-4941 \
Technical Details
Message-ID:
<GAH.93Jan22090351@trcrik.trc.mew.mei.co.jp>Path:
arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!sgiblab!adagio.panasonic.com!chorus.mei!saturn.mew!srl!gahShow Full Headers
Complete Article Headers
Newsgroups: comp.os.msdos.programmer Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!sgiblab!adagio.panasonic.com!chorus.mei!saturn.mew!srl!gah From: gah@trc.mew.mei.co.jp (Gary A. Hildebrand) Subject: V86 Mode, IOPL = 3, INT/IRET: What really happens??? Message-ID: <GAH.93Jan22090351@trcrik.trc.mew.mei.co.jp> Sender: news@srl.mew.mei.co.jp Nntp-Posting-Host: akihabara.trc.mew.mei.co.jp Organization: Matsushita Electric Works Ltd., Tokyo, Japan. Date: Fri, 22 Jan 1993 00:03:51 GMT Lines: 69