 SU.HARDW.PC.CPU (2:5020/299)  SU.HARDW.PC.CPU 
 From : Alex Iliynsky                       2:5020/23       Tue 05 Dec 95 13:52 
 Subj : [1/2] VME                                                               


Hi All!

    ⮬,  ᮡ⢥ ⠪ VME.
  p - HTML,     .   ⠩ ⠪ :)


<TITLE>Virtual Mode Extensions on the Pentium Processor</TITLE>

<P>
Of all that is known about the secrets contained in the <U>Supplement
to the Pentium Processor User's Manual</U> (&quot;Appendix H&quot;),
nothing is guarded more closely than details of the Virtual Mode
Extensions (VME) implemented in the Pentium processor and late-model
Intel486's. Even when closely reading the Pentium manuals, it
is possible that the reader doesn't notice that enhancements to
virtual-8086 mode exist. Yet the <U>Pentium Processor Family Developer's
Manual, Volume 3</U> is not silent on the subject. There are at
least 27 references to VME in the Pentium manual. In addition
to these references, another good source of information is Intel's
British VME Patent application, which is publicly available. With
a good understanding of Virtual-8086 mode (v86 mode), one could
infer most of the remaining details of VME solely from those 27
references. All that's needed to characterize the complete details
is an understanding of v86 mode, a little ingenuity, experimentation,
persistence, and no qualms about hitting the reset button to restart
a frozen computer. (For those with $12,000 to spare, an In-Circuit-Emulator
(ICE) would be helpful too.)
<H2>The need for VME.</H2>

<P>
When v86 mode was originally implemented, software writers found
two main purposes for its use. 1) DOS memory managers, and 2)
DOS sessions under a multitasking operating system (MTOS) (like
a DOS box in Windows). Under a memory manager, DOS remains a sequential
single-tasking operating system. Therefore, hardware resources
don't need to be arbitrated;[<A HREF="#Ref1">1</A>] IOPL-sensitive
instructions don't need to restricted at all. Running a DOS session
under Windows is quite different. Nearly all resources need to
be restricted. The DOS session should not have direct access to
the hardware with the ability to program any and every device.
Nor should the DOS session have the ability to directly control
the interrupt flag (IF) of the EFLAGS register. Virtual-8086 mode
has support for restricting such access, through the use of IOPL
to restrict IOPL-sensitive instructions which modify IF,[<A HREF="#Ref2">2</A>]
and the I/O permission bit map to restrict access to I/O ports.
However, there are a few shortcomings with the standard v86 mode.
<OL>
<LI>Setting IOPL to 3 provides the better performance than setting
IOPL less than 3. This setting reduces the trapping overhead,
but lets Virtual DOS Machines (VDMs) disable interrupts, a potential
integrity problem for the whole system.[<A HREF="#Ref3">3</A>]

<LI><A NAME="_Ref339538175">IOPL must be set less than 3 when
the OS needs to virtualize the interrupt flag. When a Virtual
Device Driver (VDD) needs to simulate a hardware interrupt into
a VDM, it must be able to detect when the VDM is interruptible.
Therefore IOPL must be less than 3 so that the interrupt flag
can be virtualized.[</A><A HREF="#Ref3">3</A>] Since IOPL is less
than 3, performance is significantly degraded by attempts to execute
interrupt flag sensitive (IF-sensitive) instructions which always
fault to the v86 monitor.
<LI>An operating system may allow a VDM to receive real (external)
interrupts, or virtual interrupts. This is a policy decision made
by the OS implementers. If a v86 task only receives virtual interrupts,
then it can be demand-paged, whereby it is swapped out to disk
when real memory is needed for other purposes. If the v86 task
receives real (external) interrupts, then it cannot be demand-paged,
since the interrupt handler may be paged out when the interrupt
occurs. The OS may not have enough time to bring in the entire
task before another interrupt occurs; likewise it would be too
complicated and still too time consuming to bring in just the
portion of the task which contains the interrupt service routine.[<A
HREF="#Ref4">4</A>]

<LI>All INT-n instructions cause a switch out of v86 mode. When
IOPL&lt;3, an INT-n faults to the v86 monitor. When IOPL=3, the
INT-n attempts to invoke the protected mode interrupt handler
associated with that particular interrupt (success depends on
the DPL of the gate being used). The monitor or interrupt handler
must either emulate the interrupt's functionality, or restart
the v86 task in such that it executes the interrupt itself (this
is known as reflecting the interrupt). DOS kernel routines are
accessed through software interrupts. Therefore, thousands of
interrupt calls generate thousands of transitions in and out of
v86 mode. This gives the v86 task a substantial performance disadvantage
to the same program running under DOS.
</OL>

<H2>VME fixes v86 problems</H2>

<P>
Enhanced v86 mode was designed to eliminate many of these problems,
and significantly enhance the performance of v86 tasks running
at all IOPL levels. When running in Enhanced virtual-8086 mode
(Ev86) at IOPL=3, CLI and STI still modify IF. This behavior hasn't
changed. Running at IOPL&lt;3 has changed. CLI, STI, and all other
IF-sensitive instructions no longer unconditionally fault to the
Ev86 monitor. Instead, IF-sensitive instructions clear and set
a virtual version of the interrupt flag in the EFLAGS register
called VIF.<A NAME="_Ref338813209">[</A><A HREF="#Ref5">5</A>]
Clearing VIF does not block external interrupts, as clearing IF
does. Instead, IF-sensitive instructions clear and set a virtual
version of the interrupt flag called VIF. VIF does not control
external interrupts as IF does. Rather, VIF is an indicator of
the interruptibility state of the EV86 task. Thus, the operating
system is invulnerable to a bug in a DOS program which inadvertently
attempts to disable interrupts and spin inside of a loop, as VIF
will be cleared instead, while IF will remain set. This new behavior
has some substantial benefits: performance is increased, as CLI
and STI don't cause time-consuming faults. Secondly, the complexity
of the monitor program is reduced, as it doesn't have to maintain
its own virtual interrupt flag. When the old-style v86 monitor
virtualized IF, it needed to emulate all changes to IF caused
by IF-sensitive instructions (CLI, STI, PUSHF, POPF, INT, and
IRET). Using Ev86 mode eliminates this complexity because the
CPU automatically virtualizes IF; performance increases because
IF-sensitive instructions don't fault to the Ev86 monitor.
<P>
When external interrupts are generated, such as timer ticks and
keyboard strokes, the host operating system running at CPL-0 always
intercepts these interrupts. When some interrupts occur, the current
task may not be the v86 task, it may be swapped out to disk, or
it may be in an uninterruptible state. When this occurs, the host
OS must delay sending the interrupt to the v86 task until it is
running, and ready to accept interrupts. Other interrupts may
be intended for a specific VDM, but not all VDMs (like keystrokes).
In this case, the v86 monitor needs to send a specific interrupt
to a specific VDM -- ignoring all other VDMs. Delaying and filtering
interrupts in this manner is known as <I>interrupt virtualization</I>.
Once the VDM with a virtual interrupt pending becomes interruptible,
the OS reflects the interrupt to the VDM as if a real interrupt
had occurred.
<P>
Prior to Ev86 mode, the v86 monitor needed to maintain a virtual
interrupt flag in software. The v86 monitor was forced to handle
many exceptions which were unnecessary. For example, when a virtual
interrupt was pending, further IOPL-sensitive instructions which
attempted to clear IF caused undesired faults, which then caused
the monitor to redundantly clear the virtual interrupt flag. This
problem doesn't exist in Ev86 mode. These instructions which redundantly
attempt to clear IF don't fault to the monitor. Therefore the
source code which exists to clear the software virtual interrupt
flag can be removed. In fact, while using Ev86 mode, all of the
code needed to maintain the software virtual interrupt flag can
be removed -- as the virtual interrupt flag is maintained by the
CPU itself.
<P>
Prior to Ev86 mode, software interrupts (INT-n instructions) always
caused a switch out of v86 mode. If IOPL=3, the transition occurs
through a gate associated with the interrupt;<A NAME="_Ref339689075">[</A><A
HREF="#Ref6">6</A>]
when IOPL&lt;3, the transition occurs as the result of a general
protection fault to the monitor. When IOPL=3, the monitor needs
to determine whether or not the cause of the interrupt is a software
interrupt, external interrupt or CPU-generated exception. When
IOPL&lt;3, software interrupts don't transition through their
associated gates in the IDT (they transition through the #GP gate).
In the case of software interrupts, the monitor must interpret
the opcode to determine which interrupt number needs servicing.
The monitor must then emulate the interrupt, or reflect the interrupt
back to the v86 task. External interrupts and CPU-generated exceptions
still transition through their associated gate in the IDT. For
these cases, the monitor still needs to determine the source of
the interrupt (external or CPU-exception), and take the appropriate
action. Using Ev86 mode can simplify this process, and enhance
the performance of handling software interrupts.
<P>
Software interrupt execution is controlled by a new structure
in the TSS called the interrupt redirection bit map (IR bit map).
Each bit in this new structure controls whether or not a specific
software interrupt will be invoked in a manner compatible with
the Intel386, or be invoked purely within the Ev86 task. In Ev86
mode, these interrupts may be invoked and executed without ever
leaving the Ev86 task. Using this new technique would reduce complexity
in the monitor. Interrupts which would normally fault to the monitor,
no longer would. Interrupts which would transition through the
IDT no longer would.

<H2>Overview of VME Components</H2>

<P>
VME support is enabled and disabled by setting and clearing the
VME bit in CR4 (bit 0). When enabled and running at IOPL=3, all
INT-n instructions are controlled by the interrupt redirection
bit map in the TSS.[<A HREF="#Ref7">7</A>] When running at IOPL&lt;3,
in addition to the INT-n behavior, IF-sensitive instruction are
allowed to execute without faulting to the Ev86 monitor.
<P>
The TSS has been extended to include a 32-byte interrupt redirection
bit map. 32-bytes is exactly 256 bits, one bit for each software
interrupt which can be invoked via the INT-n instruction. This
bit map resides immediately below the I/O permission bit map (see
<A HREF="#Fig1">Figure 1</A>). The definition of the I/O Base
field in the TSS is therefore extended and dual purpose. Not only
does the I/O Base field point to the base of the I/O permission
bit map, but also to the end (tail) of the interrupt redirection
bit map. This structure behaves exactly like the I/O permission
bit map, except that it controls software interrupts. When its
corresponding bit is set, an interrupt will fault to the Ev86
monitor. When its bit is clear, the Ev86 task will service the
interrupt without ever leaving Ev86 mode.
<P>
<A NAME="Fig1"><B>Figure 1</B> -- Interrupt redirection bit map
in the TSS</A>
<P>
<IMG SRC="vmepict1.gif" ALIGN="BOTTOM"><BR>

<H2>VIF and VIP EFLAGS Bits</H2>

<P>
Two new flags were added to the EFLAGS register. These flags are
intended for use when the IOPL of the Ev86 task is less than 3
(see sidebar <A HREF="CaveatsOfVME.html">Caveats Of VME (When CR4.VME=1)</A>).
They can only be purposely modified by the CPL-0 Ev86 monitor
or an interrupt service routine.
<P>
VIF is a virtualized version of the standard interrupt flag (IF).
While the Ev86 task is running, any CLI and STI instruction will
not modify the actual IF, instead these instructions modify VIF.[<A
HREF="#Ref5">5</A>]
This fact is completely hidden from the Ev86 task, as PUSHF, POPF,
INT-n, and IRET have also been modified to help hide this behavior.

<P>
The VIP flag is a Virtual Interrupt Pending flag. VIP can assist
the multitasking operating system in sending a virtual interrupt
to the Ev86 task. The easiest way to understand VIP is to explain
its use in the context of a program running on an 8086. When the
8086 is in an uninterruptible state, external interrupts remain
pending but don't get serviced. After IF is set (because of STI,
POPF, or IRET), the pending interrupt is serviced by the CPU.
VIF and VIP are intended to serve this same purpose to the MTOS
running an Ev86 task. Let's assume your Ev86 task was at the same
uninterruptible point as the previous 8086 example. A timer-tick
interrupt occurs, and the MTOS services the interrupt. During
the interrupt service routine, the MTOS decided that the Ev86
task needs to service this timer tick, and sets VIP. After returning,
the Ev86 task is still in an uninterruptible state (VIF=0). At
some later time, the Ev86 task attempts to set IF (STI, POPF,
or IRET). When this happens, the Ev86 task becomes interruptible,
and a general protection fault to the monitor immediately occurs
(#GP(0)).[<A HREF="#Ref8">8</A>]
<H2>IF-sensitive instructions</H2>

<P>
To support the new VIF and VIP flags, changes were needed to the
instructions which read and write the interrupt flag of the EFLAGS
register. CLI, STI, PUSHF, POPF, INT-n, and IRET all had to be
changed to support Ev86 mode.
<P>
When an Ev86 task is running at IOPL&lt;3, CLI, and STI clear
and set the VIF flag, instead of faulting to the Ev86 monitor,
or affecting the IF flag.[<A HREF="#Ref5">5</A>]
<P>
PUSHF copies the contents of the VIF flag to the IF position as
it pushes the FLAGS image onto the stack. This gives the appearance
to the Ev86 task that STI and CLI are really setting and clearing
IF. This appearance is necessary in case the software attempts
to check for this condition. Such a code sequence which tests
for the interrupt flag, is seen in <A HREF="#List1">Listing 1</A>.
In addition to moving the VIF to the IF on the stack image, PUSHF
always pushes an IOPL image of 3 onto the stack. It is important
to remember that the Pentium's IF-sensitive instructions behave
identically to the Intel486 when IOPL=3, even when CR4.VME=1.
Therefore, PUSHF simulates an IOPL=3 to any software wishing to
read the stack image to determine its IOPL. The actual IOPL of
the Ev86 task never changes during this process.
<P>
<A NAME="List1"><B>Listing 1</B> -- Code demonstrating how software
tests for the IF flag</A>
<PRE>
<TT>STI                             ; Enable interrupts
PUSHF                           ; Store FLAGS on stack
POP     AX                      ; Restore flags into register
TEST    AX,200h                 ; Interrupt flag set?
Jcc     label                   ; Jump on condition
</TT>
</PRE>

<P>
POPF works similar to PUSHF by copying the bit in the IF position
to VIF flag as it pops the FLAGS image from the stack. The Pentium
is careful to make sure that the <I>faked</I> IF and IOPL aren't
accidentally copied into the real IOPL during the POPF operation.
Before the FLAGS image is merged into the EFLAGS register, the
IF image is copied to the VIF slot, the IF and IOPL images are
cleared. All of the actual FLAGS register bits are cleared, except
the actual IF and IOPL. Finally, the filtered FLAGS image is merged
with the actual EFLAGS register. A side-effect of POPF is its
handling of the TF in the stack image. If the TF on the stack
image is set, then POPF causes a general protection fault before
any FLAGS values are modified (#GP(0)).
<P>
The IRET instruction behaves exactly as the POPF instruction does
with respect to IF, VIF and IOPL. IRET and POPF differ in how
they handle the trap flag from the stack image. If TF is set in
the FLAGS stack image during POPF, a #GP(0) occurs, yet for IRET
the #GP does not occur.
<P>
The INT-n instruction is the most complicated of the IOPL-sensitive
instructions. INT-n behaves exactly like PUSHF in how it handles
IF, VIF, and IOPL.[<A HREF="#Ref9">9</A>] However, one of the
enhancements to Ev86 mode is the ability of the Ev86 task to execute
software interrupts without leaving Ev86 mode. This enhancement
has been accomplished with the aid of the interrupt redirection
bit map in the TSS. When the corresponding IR bit is set, the
interrupt will be invoked in exactly the same manner as a normal
v86 task. When the corresponding bit is clear, the interrupt is
invoked as if it were executing on an 8086 processor. In other
words, a fault to the monitor is never generated, nor a transition
to the protected mode interrupt handler. The interrupt transition
and return are done entirely within the Ev86 task. The influence
of the IR bit map is best described by the pseudo-code in <A
HREF="#List2">Listing 2</A>.
<P>
<A NAME="List2"><B>Listing 2</B> - Interrupt handling description
in Ev86 mode</A>
<PRE>
<TT>N = INTERRUPT_NUMBER;
INTERRUPT_BIT_MAP_PTR = TSS_BASE-&gt;IO_PERMISSION_BASE - 32;
IF INTERRUPT_BIT_MAP_PTR-&gt;BIT_NUMBER[N]
    IF (IOPL&lt;3)
        #GP(0);
    ELSE
        GOTO INT-FROM-V86-MODE;
ELSE
    INVOKE_REAL_MODE_STYLE_INTERRUPT_FROM_Ev86_TASK(N);
</TT>
</PRE>

<H2>Conclusions</H2>

<P>
The virtual mode extensions are very useful to memory managers
and multitasking operating systems. Memory managers can primarily
benefit by the use of the interrupt redirection bit map to reduce
the number of switches to and from protected mode. This has the
added benefit of reducing the complexity of the interrupt service
routines, as they no longer have to reflect software interrupts
back to the v86 task.
<P>
Multitasking operating systems can benefit in many ways. The MTOS
benefits from interrupt redirection, and from the virtual interrupt
support. The MTOS would run with virtual mode extensions enabled,
and the Ev86 tasks running at IOPL&lt;3. This gives the MTOS full
benefit of the virtualization of interrupts. When the MTOS wishes
to send a virtual interrupt (like a virtual timer-tick) to an
uninterruptible Ev86 task, it will do so by setting VIP=1. When
the task becomes interruptible, a general protection fault occurs,
and the MTOS will send the virtual interrupt to the Ev86 task.
This would give programs which are timer-dependent (such as games)
a significant performance advantage. As an added benefit of using
the virtualization features of the CPU, even more complexity of
the Ev86 monitor can be removed. The result of using these new
features, is an Ev86 monitor that is simpler to implement and
maintain than its non-Ev86 counterpart, and software which runs
faster.<BR>

<HR>
Virtual Mode Extensions is probably a trademark of IBM, and shouldn't
have been patented by Intel because of IBM's prior art..<BR>
Pentium and Intel are trademarks of Intel Corporation. 386, 486,
586, P6, and all other numbers&#133;<B>are not!</B> <BR>
All other trademarks are those of their respective companies.


   Starder

--- IBM OS/2 Dialog Editor
 * Origin:  (C) Starder. From Home (%TEMP%)  (2:5020/23)


 SU.HARDW.PC.CPU (2:5020/299)  SU.HARDW.PC.CPU 
 From : Dima Dick                           2:5012/1.12     Fri 19 Jul 96 16:51 
 Subj : VME                                                                     


 VR>> VME -   ⥫  , __
 VR>> ᠭ 樮,    ⮣,   - ண
 VR>> ⨫ 뢠  横.

 SR> H,  p 㯮⮣      p ?   
 SR>   :-(  -   :-(

  ⠪.
   VIF - Virtual Interrupt Flag - CLI  STI   IF  VIF.
  PUSHF VIF 頥   IF.
   VIP - Virtual Interrupt Pending flag - ᫨  ⠭,  ᫥
ࠧ襭 뢠 (STI,POPF,IRET) ந GP (  ).
   IR map - interrupt redirection map  TSS (32  - 256 ) ᫨ 
⠭,  ந GPF  믮 ᮮ⢥饣 INT, 
 ࠡ⠥    DOS.

Dima

--- GoldED 2.42.G0214+
 * Origin: VPBS Station, Russia, Kurgan (2:5012/1.12)

 SU.HARDW.PC.CPU (2:5020/299)  SU.HARDW.PC.CPU 
 From : Vladimir Poletaev                   2:5020/243.66   Fri 19 Jul 96 22:33 
 Subj : VME                                                                     

Hi, All!

H-  ᠭ VME.  室  CD ROM 孨᪮ প
( 2), ࠧ襬  ⥪.  䠩
\contents\ial\processr\ppro_ug3.pdf ( ᠭ  -).

  뤥প:
 
=============================================================================
12.4.3. Method 4 Interrupt and Exception Handling

Method 4 interrupt and exception handling allows method 1 style handling when
the virtual mode extension is enabled; that is, the interrupt or exception is
directed to a protected mode handler (see Method 1 Interrupt and Exception
Handling on page 12-17). Method 4 handling is enabled when the VME flag is set 
to 1, the IOPL value is 3, and the bit for the interrupt or exception vector in 
the redirection bit map is set to 1.

12.4.4. Method 5 Interrupt and Exception Handling

Method 5 interrupt and exception handling provides a streamlined method of
redirecting soft-ware interrupts (invoked with the INTn instruction) that occurs
in virtual 8086 mode back to the 8086 programs interrupt vector table and its
interrupt and exception handlers. Method 5 handling is enabled when the VME flag
is set to 1, the IOPL value is 3, and the bit for the inter-rupt vector in the
redirection bit map is set to 0. The processor performs the following actions to
make an implicit call to the selected 8086 program interrupt or exception
handler:
1. Pushes the current values of the CS and EIP registers onto the current stack.
(Only the 16 least-significant bits of the EIP register are pushed and no stack 
switch occurs.)
2. Pushes the low-order 16 bits of the EFLAGS register onto the stack with the
NT and IOPL bits cleared.
3. Clears the IF flag in the EFLAGS register to disable interrupts.
4. Clears the TF flag, in the EFLAGS register.
5. Locates the 8086 program interrupt vector table at linear address 0 for the
8086-mode task.
6. Loads the CS and EIP registers with values from the vector table entry
pointed to by the interrupt or exception vector. Only the 16 low-order bits of
the EIP are loaded and the 16 high-order bits are set to 0.
7. Begins execution the selected interrupt or exception handler.
Exceptions do not return error codes when using this method of handling
exceptions.
An IRET instruction at the end of the handler procedure reverses these steps to 
return program control to the interrupted 8086 program.
The method 5 handling actions are virtually identical to the actions the
processor takes when handling interrupts and exception in real-address mode. The
benefit of using method 5 handling to access the 8086 program handlers is that
it avoids the overhead of method 1 handling, which requires first going to the
virtual-8086 mode monitor as described in Handling a Virtual-8086 Mode
Interrupt or Exception Through a Protected-Mode Trap or Interrupt Gate on page 
12-17 and Handling a Virtual-8086 Mode Interrupt or Exception With the 8086
Program Interrupt or Exception Handler on page 12-19.
=============================================================================

⭮,   饬 ⠬  ᠭ    ᪠, 
ᠭ VME  ⮫쪮 ࠧࠡ稪 樮 ⥬  
࠭. ;)


With best regards...
                                    Vladimir. 
--- timEd 1.01+
 * Origin: SoftMare (2:5020/243.66)


