HVM (Hardware isolation and virtualization acceleration)

HVM (Hardware Virtual Machine) is a processor technology that allows multiple operating systems to run directly on hardware without software emulation. Guest systems work with real resources, delivering performance nearly indistinguishable from a physical machine.

HVM technology is used in type-1 server hypervisors such as VMware ESXi, Microsoft Hyper-V, and KVM. It is also critical for cloud platforms like AWS and Google Cloud, as well as desktop solutions such as VirtualBox or QEMU when hardware acceleration is enabled. Without HVM, efficient operation of virtualization-level containers based on hardware extensions is impossible.

Typical HVM issues

The main difficulties arise from BIOS and processor version incompatibility, when virtualization is disabled in the motherboard settings. Another problem is vulnerabilities like VMExit, which allow a malicious guest system to attack the host. Also, I/O performance degradation can occur when guest systems generate intensive interrupts.

How HVM works

HVM uses special instructions and data structures added to the x86 architecture (Intel VT-x, AMD-V). When loading, the hypervisor switches the processor to guest mode using the VMLAUNCH or VMRESUME instruction. The processor stores the guest OS and host state in a special memory area called the Virtual Machine Control Structure (VMCS). Every critical operation of the guest system, such as accessing control registers or executing privileged instructions, automatically triggers a hardware transition (VMExit) to the hypervisor without software emulation. The hypervisor processes the event, performs the necessary actions on behalf of the guest, and returns control via VMRESUME, while the processor restores the full guest context from the VMCS. This approach eliminates the overhead of dynamic code translation and delivers near-native computational performance.

HVM features

  1. Guest mode (VMX non-root). Processors with HVM support two modes: root for the hypervisor and non-root for guests. Switching between them occurs without performance loss. In non-root mode, most instructions execute directly on hardware, eliminating binary translation overhead.
  2. Nested paging extensions (EPT/NPT). HVM includes Extended Page Tables (Intel) or Nested Page Tables (AMD). These are MMU units that perform two-level address translation: guest physical to machine physical. Hardware management of the shadow page table eliminates software traps (page faults) to the hypervisor.
  3. Virtual Machine Control Structure (VMCS). For each virtual CPU, a VMCS structure is created in memory, managed by the processor. It stores guest register states, control bits, and transition counters. The hypervisor interacts with the VMCS via VMREAD and VMWRITE instructions, minimizing manual context saving.
  4. VMXON instruction. HVM mode initialization is performed by the VMXON instruction. It transitions the processor into a state ready to run virtual machines. Upon successful activation, the hypervisor gains exclusive access to interrupt and exception management while operating in root mode.
  5. VMLAUNCH and VMRESUME. Starting a guest OS is initiated by the VMLAUNCH instruction, and returning after temporary offloading is done by VMRESUME. Both instructions cause a hardware transition to non-root mode, loading state from the current VMCS. Errors are recorded in a special VM-instruction error field.
  6. Interrupt handling in HVM. Hardware support for interrupt virtualization (APICv) allows the processor to deliver external interrupts directly to guest mode. The hypervisor can intercept only critical events such as NMI or SMI using mask bits in the VM-exit control.
  7. VM-exit and VM-entry. Transition from guest to hypervisor (VM-exit) occurs when privileged instructions are executed or mapped registers are accessed. The reverse transition (VM-entry) restores the guest context. The processor automatically saves and loads up to 32 register state fields.
  8. Shadow control registers. HVM transparently emulates CR0 and CR4 registers for the guest. Fixed bits in the VMCS determine which values are allowed. An attempt by the guest to set a prohibited bit triggers an immediate VM-exit without software checking, accelerating configuration trapping.
  9. I/O virtualization (VT-d/AMD-Vi). HVM integrates with DMA remapping technologies for direct device assignment. Using I/O address translation tables (IOMMU), a physical device can safely write directly to guest memory, bypassing the hypervisor. HVM only manages MSI interrupt mapping.
  10. IOMMU (Isolation of direct memory access addresses)
  11. Hardware timestamp support. Modern HVM implementations incorporate a virtualized timer (VMX-preemption timer). The tick counter runs in non-root mode, and when it reaches zero, a VM-exit is triggered. This provides precise CPU time quota allocation to the hypervisor without an external programmable interval timer.
  12. MSR access control. Model-specific registers (MSRs) are intercepted via bitmaps in the VMCS. The hypervisor can allow direct reading of certain MSRs by the guest (e.g., TSC) and intercept writes to others. The processor checks the bitmap on each access without software emulation.
  13. Virtual exceptions. HVM allows the hypervisor to inject hardware exceptions (page faults, division by zero) directly into the guest via the VM-entry interruption-information field. The processor automatically adjusts the stack and interrupt vector, emulating real hardware behavior for the guest OS.
  14. Protection against recursive VM-exit. A hardware mechanism prevents infinite loops in nested virtualization. HVM uses a shadow-VMCS counter to handle a guest hypervisor. If VMXON is attempted from non-root mode, the processor generates an exception rather than a recursive exit.
  15. TLB optimization. Integration of HVM with address space IDs (ASID) allows the translation lookaside buffer (TLB) to distinguish entries from different guests. When switching between virtual machines, no global TLB invalidation is required, only a tag change, reducing context switch cost to hundreds of cycles.
  16. Performance monitoring. HVM provides virtualized performance counters (PMC). A guest can read its own counters, but accessing global counters triggers a VM-exit. The hypervisor emulates aggregated statistics, preventing the guest from observing other VMs.
  17. Power management. HVM extensions support guest C-states by filtering P-state requests. HLT and MWAIT instructions in non-root mode can execute directly, reducing CPU frequency. The hypervisor only intercepts transitions to deep sleep states to preserve timer integrity.
  18. Debugging via HVM. Hardware breakpoints (DR0–DR7) work in guest mode with passthrough capability. If the Monitor Trap Flag is set in the VMCS, every guest instruction triggers a VM-exit. This allows the hypervisor to single-step through guest code without modifying its debug registers.
  19. Security and isolation. HVM ensures complete isolation through hardware protection domains. DMA from one guest to another guest’s memory is blocked by the IOMMU. The absence of shared structures between VMs (except the VMCS) prevents leaks through speculative execution side-channels, requiring additional synchronization only for cache attacks.
  20. Pure HVM limitations. Without nested page table support (EPT/NPT), memory performance degrades due to shadow page tables. Also, instructions like SGDT/SIDT, which read descriptor tables, always cause a VM-exit because their result depends on the current mode. Full performance requires the combined operation of HVM and paravirtualization.

Comparisons with HVM

  • HVM vs Software Virtualization (Binary Translation). HVM uses hardware processor extensions (Intel VT-x / AMD-V) to isolate guest OSs, whereas software virtualization emulates instructions in a binary translator without CPU support. HVM provides lower overhead and native performance but requires a modern processor. Binary Translation is compatible with older hardware but suffers from slowdowns of 10–50% depending on workload.
  • HVM vs Paravirtualization (PV). HVM runs unmodified guest OSs with full hardware isolation but does not optimize disk or network operations without additional drivers. Paravirtualization requires modifying the guest OS kernel to use hypercalls, improving I/O efficiency but reducing compatibility. Hybrid mode (PV on HVM) combines the basic isolation of HVM with accelerated PV drivers.
  • PV (Virtual machine I/O acceleration)
  • HVM vs Nested Virtualization (NV). HVM itself runs as a guest environment under a first-level hypervisor (e.g., KVM). Nested virtualization allows running a hypervisor inside an HVM guest, creating a second virtualization layer. This is useful for testing but dramatically increases latency due to double exception tracing and shadow page tables. HVM without NV is faster because the CPU directly handles VM-Exit for only one hypervisor.
  • HVM vs Containerization (Docker, LXC). HVM provides full isolation at the hardware abstraction level (its own kernel, memory, devices), ensuring strong security even for untrusted applications. Containerization uses a shared OS kernel with namespaces and cgroups, which is lighter and faster to start but provides weaker isolation. HVM is suitable for heterogeneous OSs (Windows and Linux together), while containers are only for homogeneous kernels.
  • HVM vs Firmware-based Virtualization (SMM, TEE). HVM is managed by an OS-level hypervisor (e.g., ESXi, KVM) and protects against application-level errors but is vulnerable to attacks from the host kernel. Firmware-based virtualization (System Management Mode, Trusted Execution Environment) operates at the firmware or secure enclave level (Intel SGX), providing protection from privileged software. HVM is easier to deploy and migrate, while SMM/TEE are hidden from the OS but limited in available resources.

OS and driver support

HVM requires the host OS to have a specialized hypervisor (such as KVM, Hyper-V, or VMware ESXi) that directly manages CPU context switching via VT-x (Intel) or AMD-V instructions. Guest OSs use paravirtual drivers (virtio, vmxnet3) to bypass device emulation, achieved through operation with protection rings — guest code executes in non-privileged mode with hardware acceleration, while critical instructions are intercepted by the hypervisor via nested page tables (EPT/NPT).

Security

HVM isolates virtual machines at the hardware memory level via IOMMU (Intel VT-d, AMD-Vi), preventing DMA attacks from guest to host, and also uses hardware security extensions such as trusted boot chains (UEFI Secure Boot) and measures against cache-based leaks (side-channel attacks are blocked through TLB introspection and hardware buffer clearing).

Logging

Hardware trace blocks (Intel PT, AMD LBR) in conjunction with the hypervisor allow logging of every mode transition (VM Entry / VM Exit) by cause, including MMIO access, I/O ports, and interrupts, as well as recording memory page protection violations via VMCS error registers (on x86). All events are timestamped with the TSC and written to a host ring buffer for subsequent forensics.

Limitations

HVM cannot emulate arbitrary hardware environments without performance loss — instruction set compatibility is required (the same CPU architecture, e.g., x86 on x86). Additionally, nested virtualization imposes restrictions (requires special VMCS-shadowing support), and there are no mechanisms to protect against certain power consumption attacks or temporary memory failures (RAS functions only partially solve the problem).

History and development

HVM began in 2005–2006 with the introduction of Intel VT and AMD Pacifica (later AMD-V), replacing slow full emulation (Bochs, QEMU-softmmu). Nested page technologies followed (EPT from Intel in 2009, NPT from AMD). ARM introduced similar virtualization extensions (Hyp mode in Cortex-A15, 2012). The modern stage includes hardware GPU virtualization (SR-IOV, virtual NVMe queues) and secure environments such as Intel TDX and AMD SEV for end-to-end VM state encryption.

SR-IOV (Hardware-level input-output device virtualization)