VM86 Extensions
The VME feature was first implemented in the Pentium® processor. It was migrated backwards into the later versions of the 486 and is present in all IA32 processor subsequent to the Pentium®.
Introduction
The chapter entitled “Virtual 8086 Mode” on page 329 provided a detailed description of VM86 Mode as implemented on the 386 processor. VM86 Mode operation on the early versions of the 486 was identical to operation on the 386. The Pentium® processor introduced some improvements to VM86 Mode. Whether or not these improvements are activated is controlled by CR4[VME] (VM86 Mode Extensions; see Figure 21-1 on page 491):
When CR4[VME] = 0, an IA32 processor's VM86 Mode is 100% compatible with the 386 version of VM86 Mode.
If the OS sets CR4[VME] = 1, the improved VM86 features are activated.
CR4 was implemented in the later versions of the 486 processor and is implemented in all subsequent IA32 processors. Executing a CPUID request type 1 returns the processor's capabilities in the EDX register (see Figure 21-2 on page 491). Bit 1 indicates whether or a processor supports the VME feature.
Figure 21-2. EDX After a CPUID Request Type 1
Efficient CLI/STI Instruction Handling
Background
In 386 VM86 Mode, the attempted execution of a CLI or STI instruction in a VM86 task (i.e., a DOS task) resulted in the generation of a GP exception. This caused the VMM to be executed. The VMM would have to use the pointer that had been pushed into stack memory to determine that the instruction that caused the exception was a CLI or an STI. The handling of an attempted CLI or STI execution was described in:
“Attempted Execution of a CLI Instruction” on page 365.
“Attempted Execution of the STI Instruction” on page 368.
This involves quite a bit of software/processor overhead and results in degradation of the performance of the VM86 task.
When the VM86 extensions have been enabled, a VM86 task's attempt to execute CLI or STI is handled with considerably more grace and without incurring any software/processor overhead.
CLI Handling
Refer to Figure 21-3 on page 494. When a VM86 task attempts execution of the CLI instruction and CR4[VME] = 1, the state of the EFlags[IF] bit is not affected. Rather, the processor sets EFlags[VIF] = 0 (VIF is a virtual copy of the IF bit). Its state has absolutely no effect on the processor's operation and merely records whether or not the VM86 task prefers not to be interrupted.
Assuming that EFlags[IF] = 1, it remains so and the processor's ability to recognize an externally generated hardware interrupted remains enabled.
Refer to Figure 21-4 on page 494. If an external hardware should subsequently be detected on the processor's INTR input (or is delivered to the processor's core by its Local APIC), it is recognized on the next instruction boundary. As a result, the following actions are taken:
The processor ceases executing the interrupted program.
The processor core obtains the 8-bit interrupt vector from either the external 8259A interrupt controller or from the Local APIC.
It uses the vector to index into the IDT and reads the 8-byte descriptor. Assuming that it's an Interrupt Gate or a Trap Gate (not a Task Gate), the processor pushes the CS, EIP and EFlags registers onto the stack and jumps to the handler the gate points to. This will be the Protected Mode handler for that level of interrupt.
The Protected Mode handler examines the EFlags image saved on the stack and determines that the interrupted program was a VM86 task. As a result, the handler passes control to the VMM in the OS for handling. It also passes its vector number to the VMM.
The VMM sees that EFlags[VIF] = 0, indicating that the interrupted VM86 task prefers not to be interrupted. The VMM then evaluates the vector number delivered to it by the Protected Mode handler and makes one of two determinations:
- If, in the VMM's estimation, the interrupting device can stand some delay in being serviced, it takes the following actions:
- The VMM sets a bit in a bit mask in a deferred interrupt table in memory indicating the IRQ number of the handler whose execution is being deferred until the end of the VM86 task's timeslice.
- The VMM sets EFlags[VIP] (Virtual Interrupt Pending) bit = 1 to indicate that the execution of one or more handlers have been deferred until the end of the VM86 task's timeslice.
- The VMM then returns to the next instruction of the interrupted VM86 task and resumes its execution.
- If, in the VMM's estimation, the interrupting device requires rather more timely servicing, it calls the respective handler and instructs it to service the device now. The body of the handler is executed, thereby satisfying the device's request for servicing. The handler then returns control to the interrupted VM86 task.
Figure 21-4. Interrupt Received After CLI Execution
When the VM86 task's timeslice expires, the hardware timer interrupts the processor. If the selected entry in the IDT contains a Task Gate descriptor, the interrupt causes the processor to suspend the VM86 task and switch to the OS's task scheduler. When the task scheduler determines that a VM86 task has just completed its timeslice, it examines the state of the EFlags[VIP] bit in the EFlags image saved in the now suspended task's TSS. If VIP = 1, this indicates that the execution of one or more interrupt handlers were deferred until the end of the suspended task's timeslice. The scheduler then examines the deferred interrupt table in memory, determines the handlers that need to be executed and calls each of them to service their respective devices.
STI Handling
Refer to Figure 21-3 on page 494. When a VM86 task attempts execution of the STI instruction, the state of the EFlags[IF] bit is not affected. Rather, the processor sets EFlags[VIF] = 1 (VIF is a virtual copy of the IF bit). Assuming that EFlags[IF] = 0, it remains so and the processor's ability to recognize an externally generated hardware interrupted remains disabled.
If an external hardware should subsequently be detected on the processor's INTR input (or is delivered to the processor's core by its Local APIC), it is not recognized on the next instruction boundary.
Efficient Handling of the INT Instruction
“Processor Actions When an INT nn Is Executed in VM86 Mode” on page 358 described how the processor handles the attempted execution of the INT nn instruction when it is operating in 386-compatible VM86 Mode.
When CR4[VME] = 0, a VM86 task's attempt to execute an INT nn instruction with EFlags[IOPL] < 3 resulted in the generation of the GP exception and the execution of the VMM. This caused the processor to temporarily exit VM86 Mode and enter Protected Mode where the VMM determined whether to execute the Real Mode interrupt handler for that vector or to handle the software interrupt in Protected Mode. After the interrupt was handled one way or the other, control was returned to the VMM which then returned control back to the the next instruction in the VM86 task. All of this software overhead negatively affects the performance of the VM86 task.
When CR4[VME] = 1, the processor's handling of a VM86 task's attempt to execute an INT nn instruction is streamlined. Refer to Figure 21-5 on page 496. The processor uses the nn value (i.e., the vector) to index into the TSS's Interrupt Redirection bit map. The processor reads the map byte containing the bit corresponding to the nn value. If the bit = 0, the processor takes the following actions:
It pushes the low-order 16 bits of the EFlags register onto the stack with the NT and IOPL bit fields cleared.
It pushes the CS:IP onto the current stack (only the 16 lsbs of EIP are pushed and no stack switch occurs).
It clears EFlags[IF] to disable recognition of external hardware interrupts.
It clears EFlags[TF] to disable single-stepping (if it was enabled).
It loads CS:EIP with the start address of the handler pointed to by the nn value (i.e. the vector number; nn is multiplied by 4 to yield the linear start address of the selected IDT entry). The IDT starts at linear memory address 00000h in the 1MB address space of the VM86 task. Only the 16 lsbs of EIP are loaded (the 16 msbs of EIP are set to 0).
The processor begins executing the selected interrupt handler.
The IRET instruction at the end of the handler reverses these steps to return control to the interrupted 8086 program.
