How to Solve Virtualization Challenges with VT-x and VT-i

Submit New Article

Last Modified On :   October 27, 2008 4:11 PM PDT
Rate
 


Challenge

Address virtualization challenges on both IA-32 and Itanium®-based systems. Intel® Virtualization Technology is not the same for IA-32 and Itanium architectures for many reasons, including the fundamental differences between those architectures.

Solution

Make use of VT-x and VT-i technologies, according to the needs of a particular architecture. The IA-32 version of Intel Virtualization Technology is referred to as VT-x, and documentation on VT-x can be found in “Intel Virtualization Technology Specification for IA-32 processors (VT-x)” [PDF 960KB]. The Intel Itanium architecture version is referred to as VT-i, and documentation on VT-i can be found in “Intel Virtualization Technology Specification for the Intel Itanium Architecture (VT-i)” [PDF 792KB]. Details about these specific virtualization architectures are available in the following related items:

 

The following architectural comparison will also help to explain how both sets of virtualization technology work to address architectural issues:

  • Address-space compression. VT-x and VT-i provide two different techniques for solving address-space compression problems. With VT-x, every transition between guest software and the virtual machine monitor (VMM) can change the linear-address space, allowing the guest software full use of its own address space. The VMX transitions are managed by the virtual machine control structure (VMCS), which resides in the physical-address space, not the linear-address space. With VT-i, the VMM has a virtual-address bit that guest software cannot use. A VMM can conceal hardware support for this bit by intercepting guest calls to the processor abstraction layer (PAL) procedure that reports the number of implemented virtual-address bits. As a result, the guest will not expect to use this uppermost bit, allowing the VMM exclusive use of half of the virtual-address space.
  • Ring-aliasing and ring compression. VT-x and VT-i eliminate ring-aliasing problems because they allow a VMM to run guest software at its intended privilege level. Instructions such as PUSH (of CS) and br.call cannot reveal that software is running in a virtual machine. VT-x also eliminates ring compression problems that arise when a guest OS executes at the same privilege level as guest applications.
  • Non-faulting accesses to privileged state. VT-x and VT-i avoid problems of non-faulting accesses to privileged state in two ways: by adding support that causes such accesses to transition to a VMM and by adding support that causes the state accessed to become unimportant to a VMM. A VMM based on VT-x does not require control of t he guest privilege level, and the VMCS controls the disposition of interrupts and exceptions. Thus, it can allow its guest access to the GDT, IDT, LDT, and TSS. VT-x allows guest software running at privilege level 0 to use the instructions LGDT, LIDT, LLDT, LTR, SGDT, SIDT, SLDT, and STR. With VT-i, the thash instruction causes virtualization faults, giving a VMM the opportunity to conceal any modifications it may have made to the VHPT base address.
  • Guest transitions. Guest software cannot use the IA-32 instructions SYSENTER and SYSEXIT if the guest OS runs outside privilege level 0. With VT-x, a guest OS can run at privilege level 0, allowing use of these instructions. With VT-i, a VMM can use the virtualization-acceleration field in the VPD to indicate that guest software can read or write the interruption-control registers without invoking the VMM on each access. The VMM can establish the values of these registers before any virtual interruption is delivered and can revise them before the guest interruption handler returns.
  • Interrupt virtualization. VT-x and VT-i both provide explicit support for the virtualization of interrupt masking. VT-x includes an external-interrupt exiting VMexecution control. When this control is set to 1, a VMM prevents guest control of interrupt masking without gaining control on every guest attempt to modify EFLAGS.IF. Similarly, VT-i includes a virtualization-acceleration field that prevents guest software from affecting interrupt masking and avoids making transitions to the VMM on every access to the PSR.i bit.

    VT-x also includes an interrupt-window exiting VM-execution control. When this control is set to 1, a VM exit occurs whenever guest software is ready to receive interrupts. A VMM can set this control when it has a virtual interrupt to deliver to a guest. Similarly, VT-i includes a PAL service that a VMM can use to register that it has a virtual interrupt pending. When guest software is ready to receive such an interrupt, the service transfers control to the VMM via the new virtual external interrupt vector.
  • Access to hidden state. VT-x includes in the guest-state area of the VMCS fields corresponding to CPU state not represented in any software-accessible register. The processor loads values from these VMCS fields on every VM entry and saves into them on every VM exit. This provides the support necessary for preserving this state while the VMM is running or when changing VMs.

 

Resources

Intel Virtualization Technology

Software Developer FAQ: Intel® Virtualization Technology