VMCB (Virtual Machine state data structure)

VMCB is a memory block that the processor uses to save and load the complete state of a guest virtual machine on every entry and exit. It describes processor registers, interrupt vectors, and control settings for the hypervisor.

The scope of VMCB application covers hardware virtualization on AMD architecture processors with AMD-V technology support. This structure is a central element in building type 1 and type 2 hypervisors, enabling context switching between host and guest. Without VMCB, platforms such as KVM, Xen, or VMware ESXi cannot function on AMD hardware, as it physically defines the behavior of the guest processor during instruction execution.

AMD-V (Hardware virtualization using the processor)KVM (Turns the Linux kernel into a hypervisor)

Typical issues when working with VMCB include corruption of guest state fields due to synchronization errors in hypervisor code, leading to virtual machine crashes or data corruption. Common problems include incorrect configuration of guest page table pointers causing address translation errors, and improper emulation of interrupt control bits resulting in complete loss of interrupts. Migrating VMCB between processor cores without proper cache and TLB flushing also creates difficulties.

VMCB operation principle

The operating principle is based on atomic state switching. When the hypervisor launches a virtual machine with the VMRUN instruction, the processor reads the physical address of the VMCB and loads from it the segment registers, control registers CR0, CR2, CR3, CR4, as well as general-purpose registers and the guest instruction pointer. The VMCB field contains event intercept masks that determine under which guest actions control will return to the hypervisor: for example, when executing privileged instructions, I/O operations, or accesses to model-specific registers. The processor begins executing guest code from the context described in the VMCB.

When a condition programmed into the intercept bit fields occurs, a virtual machine exit happens. At this moment, the processor automatically saves the current guest state back to the VMCB: it records the exit reason in the exit code field, writes the values of all modified registers, and saves the offset of the instruction that triggered the intercept. After this, the processor loads the previously saved host registers from a separate memory area and transfers control to the hypervisor. The hypervisor analyzes the exit code in the VMCB, emulates the required hardware, or handles the exceptional condition, then modifies the guest state in the VMCB if necessary and executes VMRUN again. Thus, VMCB serves as a deterministic interface between hypervisor logic and the microarchitectural state of the processor, enabling full isolation and strict control over the guest environment.

VMCB functionality

  1. VMCB Structure as a Two-Component Block. VMCB (Virtual Machine Control Block) is a page-aligned data structure logically divided into two key areas: the Control Area and the Guest State Save Area. These areas provide the interface between the hypervisor and AMD-V hardware virtualization.
  2. Control Area and Intercept Vector. The control area contains bitmaps (intercepts) that determine conditions for forced exit from guest mode (#VMEXIT). This includes intercept vectors for I/O operations, exceptions, and MOV CRx instructions. Configuring these fields allows the hypervisor to maintain complete control over the execution environment.
  3. VMExit (Hypervisor interception of VM control)
  4. Permission Table Pointers. The VMCB control area holds physical addresses of auxiliary structures: IOPM (I/O Permission Map) and MSRPM (MSR Permission Map). These bitmaps precisely define which I/O ports and which model-specific registers (MSRs) the guest OS may use directly without generating a hypervisor intercept.
  5. Exit Code and Exit Information Fields. When an event causing #VMEXIT occurs, the processor fills the exit reason code (Exit Code) in the VMCB control area, along with Exit Info 1 and Exit Info 2 fields. This data details the nature of the interruption, allowing the hypervisor to identify the event source and correctly emulate the required behavior.
  6. Nested Virtualization Control. When using nested SVM, the guest VMCB address is stored in the nested_ctl field. The hardware checks the state of guest control registers (CR3, CR4) for MBZ (Must-Be-Zero) bits before executing the VMRUN command, ensuring isolation and validity when launching a nested hypervisor.
  7. SVM (Full hardware isolation of virtual machines)
  8. Event Injection Field and Interrupt Vector. VMCB allows injecting virtual interrupts or exceptions directly before entering the guest context. The event_inj and event_inj_err fields encode the vector number and error code, enabling the hypervisor to deliver asynchronous events without interfering with the guest execution flow.
  9. Guest State Save Area. The Save Area contains a snapshot of all major guest registers (CR0, CR3, CR4, RSP, RIP, RFLAGS) at the time of the last exit. When launching the guest with the VMRUN instruction, the processor loads the CPU state from this section, restoring the execution context.
  10. Processor State Load and Save. For performance optimization, AMD-V uses the VMLOAD and VMSAVE instructions. They load or save an extended set of registers (GDTR, LDTR, segment selectors, and cache descriptors) that is not automatically handled by the VMRUN instruction during context switching.
  11. Clean Fields Mechanism. To minimize redundant write operations to memory, VMCB uses a clean bitmap. By indicating which parts of the Save Area have not been modified, the hypervisor allows the processor to skip saving them on the next #VMEXIT, reducing latency critical for heavily loaded systems.
  12. Address Space Identifier (ASID) Management. The ASID field in the control area allows tagging TLB (Translation Lookaside Buffer) entries with a specific virtual machine identifier. This avoids flushing the entire TLB when switching between VMs, significantly improving performance by preserving warmed address translations.
  13. Interrupt Filtering and Virtual APIC. Advanced VMCB features include support for AVIC (Advanced Virtual Interrupt Controller) through the avic_vapic_bar and avic_backing_page fields. This allows hardware to route interrupts directly to a running guest without exiting to the hypervisor, dramatically accelerating I/O processing.
  14. Timer Configuration and TSC Offset. The tsc_offset field allows the hypervisor to hide real processor time by adding an arbitrary offset to the timestamp counter (TSC) readings for the guest. This is necessary to ensure time consistency when migrating virtual machines between physical servers.
  15. Shadow Stack Mode and Interrupt Management. The Virtual Interrupt Masking mechanism manages interrupt delivery through the int_ctl and int_state fields. Manipulating the V_IRQ and V_INTR_PRIORITY flags allows the hypervisor to simulate an interrupt controller at the hardware level, holding or delivering requests according to priority.
  16. Next RIP and Instruction Length Handling. For complex emulations of intercepted instructions, VMCB contains the next_rip and insn_len fields. They inform the hypervisor about the return address and the length of the instruction that caused the intercept, enabling advanced emulation and correct continuation of guest code execution.
  17. Extension for SEV-ES Guests. In the context of AMD SEV-ES (Secure Encrypted Virtualization – Encrypted State), VMCB is modified via a union with the host_sev_es_save field. The encrypted guest state is stored in a separate VMSA structure, while VMCB is used only to save the host state during encrypted sessions.
  18. Global Interrupt Flag (GIF) Control. The hardware manages the GIF flag through VMCB fields, determining the possibility of physical interrupt delivery. When entering the guest with the VMRUN instruction, manipulations with RFLAGS.IF must be synchronized with the V_INTR_MASKING state to avoid hardware races and leakage of the interrupt shadow stack.
  19. MBZ Bit Validation and Security. The processor hardware performs strict checking of VMCB fields before executing VMRUN. Any non-zero values in reserved (MBZ) bits of CR3 or CR4 cause the operation to terminate immediately with an error, protecting the system from inconsistent or malicious hypervisor state.
  20. Nested VMCB Synchronization Strategies. When implementing nested virtualization, changes to the shadow VMCB require deferred processing. Calls to nested_svm_vmrun_msrpm are deferred until the KVM_REQ_GET_NESTED_STATE_PAGES handler, allowing userspace to configure memory maps before actually launching the nested guest.
  21. TLB Caching Management via ASID. The tlb_ctl field is used to invalidate translations for a specific address space. The hypervisor can selectively flush the TLB cache for a virtual machine with a given ASID without affecting the hypervisor or other guests, which is critical for hot memory reallocation operations.
  22. Physical VMCB Size Specification. The architecturally fixed size of VMCB is 4096 bytes, corresponding to one memory page. The control field is limited to the first 1024 bytes, while subsequent areas are allocated for the Save Area and reserved spaces, simplifying alignment and data access by the processor.

Comparisons

  • VMCB vs VMCS. VMCB (AMD) and VMCS (Intel) are equivalent hardware structures for virtual machine control, storing guest state and intercept settings. The key difference lies in implementation: while VMCB uses a Save Area model for automatic host context save and restore via VMRUN, VMCS operates with Host State and Guest State domains during VMEntry and VMExit transitions.
  • VMCS (Virtual Machine control structure)
  • VMCB vs kvm_vcpu. VMCB is a specification of an AMD-V hardware block with which the processor directly interacts, while kvm_vcpu is a purely software structure of the Linux kernel serving as a wrapper for VMCB. VMCB is only responsible for copying registers and intercept instructions, whereas kvm_vcpu manages high-level tasks: thread scheduling, software interrupt queues, and LAPIC virtual device state.
  • VMCB vs MSR_VM_HSAVE_PA. These are not competitors but links in the same context-saving chain. VMCB stores the guest machine state, while the memory area pointed to by the MSR_VM_HSAVE_PA register is reserved for saving the host (VMM) state when the guest is launched with the VMRUN instruction. VMCB loads guest registers, and the Host Save Area accumulates a snapshot of the hypervisor for returning control.
  • VMM (Hardware resource isolation and emulation)
  • VMCB vs ARM64 EL2 Registers. Unlike x86 systems where VMCB is a structure in RAM, ARM64 implements virtualization management through direct EL2 system registers without using an analogue of VMCB. This gives the ARM architecture an advantage in low context-switching latency by eliminating the memory access stage for parsing structures like VMCB, but it lacks the flexibility of complex software post-processing.
  • VMCB vs Nested VMCB. When nested virtualization is enabled, the guest hypervisor creates its own VMCBs to manage sub-guests, while the L0-level VMCB is managed by the host hypervisor. Control conflict is resolved through mandatory hardware intercept of the VMRUN instruction inside the guest: any attempt by guest software to execute VMRUN causes a VMEXIT, allowing the host to emulate or relay the guest VMCB to the physical one.

OS and driver support

A virtual machine does not have direct access to the hardware VMCB; instead, the hypervisor (e.g., KVM) creates a shadow copy of the structure, where VMRUN, VMLOAD, and VMSAVE operations are emulated for the guest OS. When the guest system executes the VMRUN instruction, the hypervisor intercepts control, copies states from the guest VMCB to the hardware VMCB, checks and modifies control fields (e.g., I/O permission maps), and then launches the guest environment on the actual hardware. For nested virtualization, an additional shadow block (vmcb02) is allocated, which becomes active during the execution of nested guest code, allowing an OS inside a virtual machine to run its own hypervisors.

Security

Security is built on strict separation of VMCB pointers and controlled access to structure fields, so that the guest OS cannot manipulate other VMs data or affect the host hypervisor operation. Hardware support includes checking the ASID (Address Space Identifier) in the TLB tag, preventing access to cached address translations of another virtual machine; in the shadow VMCB, the hypervisor forcibly clears bits that allow direct hardware access. Vulnerability CVE-2026-43133 clearly demonstrates the risk: due to an emulation error, a nested guest could use VMLOAD and VMSAVE to operate with another vmcb02 block instead of vmcb01, potentially opening access to the upper-level hypervisor state.

Logging

Logging actions with VMCB is implemented through a mechanism of intercepting critical instructions and analyzing counter fields upon virtual machine exit (VMEXIT). When the guest OS attempts to modify key parameters in the control block, the hypervisor compares current values with reference ones in the shadow copy and records discrepancies in the system log. AMD patent documentation reveals a system of field partition tables where the hypervisor logs accesses to specific VMCB addresses for debugging nested environments, recording the history of changes and synchronizations between parent and child blocks.

Limitations

The AMD SVM hardware architecture imposes a fundamental limitation: the processor can operate with only one active VMCB at any given time, which precludes simultaneous execution of multiple guest contexts on a single physical core. Each VMCB block is strictly bound to a specific virtual CPU and cannot be shared between them without full state synchronization. Additionally, optimizations such as accelerated interrupt delivery (AVIC), when enabled, disable the virtual interrupt fields (V_IRQ) in the VMCB control part, forcing the hypervisor to rely exclusively on event injection, which reduces the performance of software-based interrupt controller emulations.

History and evolution

Initially introduced as a simple structure for saving and restoring processor state for VMRUN and VMSAVE instructions, VMCB evolved into a complex multi-level interface with support for nested virtualization, where concepts of parent and child pointers for recursive hypervisor launching appeared. Further development added enlightened fields (Enlightened VMCB) at offset 0x3E0 for direct hypercalls bypassing expensive VMEXITs, as well as fields for integration with SEV memory encryption and the Secure AVIC protocol. In the current version of the AMD64 Architecture Programmer’s Manual, the structure describes dozens of control bits and segment save areas, while hypervisors like KVM and Hyper-V implement complex shadow copy systems to support all hardware extensions.

Latest publications