Oracle XEN, VT-x and VT-i

When running virtual machines with Oracle VM you have basically 2 options, you can run paravirtualization or hardware virtualization. When running hardware virtualization with oracle VM you have a closer connection to the CPU, however the CPU has to support that you are running in hardware virtualization mode. When running in hardware virtualization mode all commands are send to the CPU where during a paravirtualization setup some commands are filtered.

When running for example windows on a XEN or Oracle VM machine you will need to have a hardware platform that enables hardware virtualization. If not you will not be able to run windows virtually on your Oracle VM machine. For the intel processors the most are proving you with VT-x or VT-i support, you can check out the current processors at the intel website and get more details there. http://www.intel.com/products/processor_number/eng/

VT-x is the code name for virtualization support for the IA-32 (Intel Architecture, 32-bit), often generically called x86 or x86-32 processors. VT-i is the code name for virtualization support for the IA-64 processors.

Some of the things the intel VT-x and VT-i technology is doing an helping XEN and Oracle VM are the following:

"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."

For more information about the br.call processor instruction you can look at this intel document. The IA-64 br.call instruction is the equivalent of the x86 CALL instruction. Microsoft has a article the MSDN website with more information about the IA-64 registers.

"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."

LGDT : Load Global Descriptor Table Register
LIDT : Load Interrupt Descriptor Table Register
LLDT : Load Local Descriptor Table Register
LTR : Load Task Register
SGDT : Store Global Descriptor Table Register
SIDT : Store Interrupt Descriptor Table Register
SLDT : Store Local Descriptor Table Register
STR : Store Task Register

"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."

SYSENTER: Executes a fast call to a level 0 system procedure or routine. This instruction is a companion instruction to the SYSEXIT instruction. The SYSENTER instruction is optimized to provide the maximum performance for system calls from user code running at privilege level 3 to operating system or executive procedures running at privilege level 0.

SYSEXIT: Executes a fast return to privilege level 3 user code. This instruction is a companion instruction to the SYSENTER instruction. The SYSEXIT instruction is optimized to provide the maximum performance for returns from system procedures executing at protections levels 0 to user procedures executing at protection level 3. This instruction must be executed from code executing at privilege level 0.

You can find the complete IA-32 Opcode Dictionary at the modseven.de website or via google.

"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."