home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / msdos / programm / 12319 < prev    next >
Encoding:
Text File  |  1993-01-21  |  3.8 KB  |  81 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!sgiblab!adagio.panasonic.com!chorus.mei!saturn.mew!srl!gah
  3. From: gah@trc.mew.mei.co.jp (Gary A. Hildebrand)
  4. Subject: V86 Mode, IOPL = 3, INT/IRET:  What really happens???
  5. Message-ID: <GAH.93Jan22090351@trcrik.trc.mew.mei.co.jp>
  6. Sender: news@srl.mew.mei.co.jp
  7. Nntp-Posting-Host: akihabara.trc.mew.mei.co.jp
  8. Organization: Matsushita Electric Works Ltd., Tokyo, Japan.
  9. Date: Fri, 22 Jan 1993 00:03:51 GMT
  10. Lines: 69
  11.  
  12. All,
  13.  
  14. The sections for Virtual 8086 mode in the Intel 386/486DX programmer's
  15. reference manuals talk about how the INT and IRET instructions can be
  16. protected from execution when in V86 mode, by setting an IOPL of less than
  17. 3.  Since V86 mode runs with an effective CPL of 3, an attempt to execute
  18. either of these instructions (and a few others which could manipulate the
  19. interrupt flag) will result in a General Protection exception (the infamous
  20. exception 13).  But what really happens when the IOPL *is* 3?
  21.  
  22. I can imagine two scenarios for the case of INT:
  23.  
  24.   1.  It works just like a hardware interrupt or CPU exception in V86
  25.       mode, chaining through the protected mode IDT, the handler for which
  26.       might then have to distinguish between software interrupts and other
  27.       cases before taking action
  28.  
  29.   2.  It works just like a software interrupt in 386/486 real mode,
  30.       chaining through the 8086 interrupt table (now that I think of it
  31.       probably unlikely, since even in real mode the IDTR determines the
  32.       base and limit of the 8086 interrupt table, unlike a real 8086/8, and
  33.       the IDTR would already be pointing to a protected mode IDT for the
  34.       benefit of V86 mode)
  35.  
  36. Even though the second scenario might be better than the first for some
  37. cases, the first is still highly reasonable and if not desired, then just
  38. set IOPL less than 3 and completely emulate what you want.  But more
  39. importantly, what about the case for IRET?  The pseudocode for the
  40. instruction in the Intel documentation just shows the generation of a
  41. General Protection exception when V86 mode is active, which would indicate
  42. the value of IOPL doesn't matter.  This can't be right.  So again, I can
  43. imagine two scenarios:
  44.  
  45.   1.  It's sort of like an IRET in protected mode, but not exactly,
  46.       since one cannot expect saved values of all the segment registers or
  47.       even a 32-bit IP to be on the stack, which will be a priveledge level
  48.       3 stack anyway.
  49.  
  50.   2.  It works just like an IRET in 386/486 real mode, popping IP,
  51.       CS, and FLAGS off the stack to resume execution at the interrupted
  52.       procedure.
  53.  
  54. So will IOPL=3 really work for V86 mode?  If the second scenario for IRET
  55. was what happened, then the following method could be used for reflecting
  56. an arbitrary software interrupt to real mode:
  57.  
  58.   1.  Depending on how INT's are interpreted, either the exception
  59.       handler in the V86 monitor performs an IRET to the real-mode code
  60.       pointed to by the 8086 interrupt table at address 0, or that happens
  61.       automatically care of the CPU.
  62.  
  63.   2.  When the real-mode interrupt handler exits with IRET, values on its
  64.       stack saved by the V86 monitor handler or CPU allow it to return
  65.       straight to the original calling procedure.
  66.  
  67. If IRET acts any differently, probably both the interrupt and return would
  68. need to be emulated using IOPL<3, which complicates things somewhat.
  69.  
  70. Any protected mode programming gurus want to tackle this one?  I'm all
  71. ears (actually eyes :-)!
  72.  
  73. Thanks in advance,
  74.  
  75. Gary
  76. --
  77. / Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
  78. /  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
  79. /   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
  80. /    Tokyo 108, JAPAN                Tel:      03-3452-4941            \
  81.