AMD-V (Hardware virtualization using the processor)

AMD-V is a hardware virtualization technology built into the processor. It allows a single physical computer to run multiple isolated operating systems simultaneously without significant performance loss. The processor takes on part of the work that was previously done by software, making virtual machines fast and stable.

This technology is used to run virtual machines on personal computers and servers. It enables the creation of isolated test environments for development, running outdated or incompatible applications, and consolidating multiple servers onto a single physical device. The technology is in demand in data centers and cloud services to optimize resources and improve equipment efficiency.

One common problem is the conflict of AMD-V with Windows security components such as Hyper-V or core isolation. In this case, the technology does not work, and the system may throw a resource busy error. Outdated driver versions, incorrect BIOS settings, or conflicts with certain anti-cheat systems in games can also lead to failures or the inability to run virtual machines.

How AMD-V works

The core of AMD-V is based on separating processor modes into guest and host. A special hypervisor program launches the guest operating system using a new processor instruction that loads its state from a management data structure. The guest system operates with virtual hardware, and when it attempts to execute a critical command or a hardware interrupt occurs, the processor automatically intercepts the event and returns control to the hypervisor via the guest mode exit mechanism. At this point, the hypervisor emulates the required operation and transfers control back to the virtual machine. Acceleration is achieved through hardware support for memory address translation — Nested Page Tables technology directly converts the guest system’s virtual addresses into physical addresses of the real memory. An additional mechanism, the tagged translation lookaside buffer, assigns each virtual machine a unique identifier, which avoids a complete cache flush of addresses when switching between tasks and significantly speeds up multitasking environments.

AMD-V functionality

  1. Basic interception mechanism and guest machine execution. The AMD-V function (SVM) introduces a new execution mode for guest systems into the x86 architecture, based on hardware state switching. The central control element is the VMCB (Virtual Machine Control Block), which stores the guest state and control settings. The VMRUN instruction starts guest execution, and the processor hardware automatically exits with an EXITCODE reason to the host hypervisor when specified events occur.
  2. VMCB (Virtual Machine state data structure)SVM (Full hardware isolation of virtual machines)
  3. Guest state control via VMCB. The VMCB is structurally divided into a Control Area and a Save Area. In the Save Area, the processor captures the full CPU context of the guest: general-purpose register values, segment registers, and control flags such as CR0, CR3, CR4, and EFER. The hardware virtualization control unit uses this data to accurately restore the execution environment after each guest exit (VMExit).
  4. VMExit (Hypervisor interception of VM control)
  5. Clean Bits mechanism. To minimize the overhead of guest entry and exit operations, AMD-V employs a clean bits mechanism in the VMCB. The hypervisor sets the corresponding bits, signaling to the processor that certain VMCB fields have not been modified since the last exit. The processor, in turn, skips their reloading during the next VMRUN execution, significantly reducing context switching overhead.
  6. Hardware support for nested memory addressing. Nested Page Tables (NPT) technology, also known as Rapid Virtualization Indexing (RVI), provides a second level of address translation entirely in hardware. The guest operating system manages its own page tables, translating virtual addresses to guest physical addresses (GVA→GPA). The processor’s NPT walker then translates guest physical addresses to real host physical addresses (GPA→HPA), eliminating the need for shadow page tables and their associated software overhead.
  7. Shadow Page Tables (Isolation of guest OS page tables)NPT (Second-level address translation for virtualization)
  8. Address space identifier management. For each running virtual processor, AMD-V requires the assignment of a unique Address Space Identifier (ASID). The ASID tag is associated with entries in the Translation Lookaside Buffer (TLB), which allows distinguishing translations of different virtual machines without completely flushing the TLB when switching between them. This hardware tagging is critically important for maintaining high performance and data isolation at the processor’s translation cache level.
  9. Event interception and exit management. The processor provides fine-grained control over the reasons for guest exit via the intercept field in the VMCB control area. The hypervisor can selectively configure interception for the execution of HLT, IN/OUT, RDMSR/WRMSR instructions, and other events. When the guest system executes an intercepted instruction, the hardware immediately suspends it, saves the exit reason in EXITINFO1 and EXITINFO2, and transfers control to the hypervisor’s handler.
  10. Accelerated interrupt processing with AVIC. Advanced Virtual Interrupt Controller (AVIC) is a hardware extension of AMD-V that moves the logic of interrupt routing and delivery from the software hypervisor to the processor die. AVIC allows the guest system to process interrupts without exiting to the hypervisor when the target virtual processor is running on a physical core. The hardware directly modifies the interrupt request registers in the guest’s virtual APIC and delivers the interrupt vector via a Doorbell mechanism.
  11. Hardware support for nested virtualization. The AMD-V extension for nested virtualization allows running a hypervisor inside a virtual machine, providing it access to SVM functions. Two levels of VMCB are created for this: vmcb01 stores the state of the first-level guest (L1), and vmcb02 emulates the hardware VMCB for the nested hypervisor (L2). The processor handles switching between L1 and L2, intercepting VMRUN and VMSAVE instructions executed by the guest to ensure complete isolation.
  12. Secure Encrypted Virtualization (SEV) technology. As an architectural extension of AMD-V, Secure Encrypted Virtualization (SEV) provides transparent encryption of the entire virtual machine memory using a key unique to each VM. A special encryption bit (C-bit) is set in the NPT tables, instructing the memory controller to apply encryption to the page using the key associated with the current ASID. This makes guest data unreadable even to the hypervisor, implementing a zero-trust computing model.
  13. Key management via the secure processor. To manage the lifecycle of encrypted SEV machines, a dedicated hardware unit is used — the Platform Security Processor (AMD-SP). This coprocessor generates cryptographic keys, manages guest system launch, and executes hypervisor commands such as initial image encryption. Interaction with the AMD-SP is carried out through a specialized software interface, KVM_MEMORY_ENCRYPT_OP and ioctl commands in KVM.
  14. KVM (Turns the Linux kernel into a hypervisor)
  15. Register state protection with SEV-ES. The SEV-Encrypted State (SEV-ES) extension adds protection of the processor context during guest exits to memory encryption. The Guest State Save Area (VMSA) is now separated from the VMCB and encrypted, preventing it from being read by the hypervisor. When an event requiring an exit occurs, the processor saves the encrypted registers, and the guest system uses a special GHCB communication block to selectively provide only the minimum necessary information to the hypervisor.
  16. Guest launch attestation. Before transferring confidential data to an encrypted virtual machine, SEV provides a cryptographic attestation mechanism for verifying its integrity by the guest owner. During the launch process, the LAUNCH_MEASURE command calculates a unique hash, which includes the contents of the firmware, kernel image, and VMSA. The owner can compare the received measurement against the expected baseline to ensure that the execution environment on the infrastructure provider’s side has not been compromised.
  17. Interrupt injection and NMI handling. AMD-V provides deterministic mechanisms for injecting events into the guest system. The EVENTINJ field in the VMCB control area allows the hypervisor to schedule the delivery of an interrupt, exception, or non-maskable interrupt upon the next guest entry. For regular interrupts, the V_IRQ mechanism can be used, forcing the guest to process the vector immediately after the interrupt flag IF is opened, emulating the hardware logic of an interrupt controller.
  18. Software model and capability detection. The availability of AMD-V features and its extensions is determined dynamically via the CPUID instruction. The SVM flag in CPUID function 0x80000001[ECX] indicates basic support for the technology. The presence of NPT, AVIC, and various generations of SEV is identified through CPUID leaves 0x8000000A and 0x8000001F. This detection model allows the hypervisor to adapt at runtime to the hardware capabilities of the specific processor generation.
  19. Optimization of MSR operations. AMD-V allows the creation of permission maps for access to Model-Specific Registers (MSRs) to avoid costly guest exits. The hypervisor configures MSRPM (MSR Permission Map) bitmaps, which determine whether a guest’s access to a specific register should be intercepted. Reading or writing registers marked as allowed is performed directly by the guest system without generating an exit event, significantly accelerating workloads sensitive to the execution path.
  20. Shadow stack and execution security management. Modern versions of AMD-V integrate with hardware security technologies such as Shadow Stack and Indirect Branch Tracking. The processor is capable of enforcing CET (Control-flow Enforcement Technology) security policies inside the guest, intercepting violations and reporting them to the hypervisor. This allows virtualization of protection against Return-Oriented Programming (ROP) attacks without modifying guest software.
  21. Virtualization and interrupt flag handling. The GIF (Global Interrupt Flag) logic in the AMD-V architecture is a critical addition to the guest’s standard IF flag. While IF controls interrupt masking inside the guest, GIF manages the ability to deliver interrupts from the host and is completely disabled by hardware during the processing of certain critical exits. This flag guarantees that the hypervisor will not receive an interrupt while the VMCB is in an unstable state during guest exit processing.
  22. Migration and live context switching. AMD-V extensions support Tagged TLB and fast state saving mechanisms necessary for the live migration of virtual machines between physical servers. The processor provides atomic operations for saving the entire virtual machine context into the VMCB without security degradation, and ASID technology allows a migrated VM to continue working on a new host without collisions in address translation caches.
  23. Integration with paravirtualized drivers. Despite full hardware support for full virtualization, the AMD-V interface is designed for efficient coexistence with paravirtualized I/O. Hardware guest exits are processed faster when the hypervisor emulates standard PCI devices, but maximum network and disk throughput is achieved using direct hardware access techniques that bypass emulation (Device Passthrough) with IOMMU support.
  24. IOMMU (Isolation of direct memory access addresses)

Comparisons

  • AMD-V vs Intel VT-x. Both technologies solve the ring-transition problem by introducing a new privilege level for the hypervisor, allowing the guest OS to run at ring 0 without modifications. The difference is in the names: AMD calls these protected virtual machines SVM, while Intel calls them VMX, but the fundamental approach to intercepting sensitive instructions is practically identical.
  • Intel VT-x (Hardware Virtualization of the CPU)
  • AMD-V (RVI) vs Intel VT-x (EPT). Unlike Intel EPT, which came later, AMD was the first to introduce hardware support for nested page tables — Rapid Virtualization Indexing (RVI). RVI allows the guest OS to manage its page tables directly, while EPT does the same in the Intel architecture, reducing the load on the hypervisor during address translation.
  • EPT (Hardware second-level memory address translation)
  • AMD-V (AVIC) vs Intel VT-x (Posted Interrupts). Both combat virtual interrupt latencies but implement it differently. AMD’s Advanced Virtual Interrupt Controller (AVIC) allows guest OSes to directly interact with the local APIC, whereas Intel uses the Posted Interrupts mechanism for accelerated delivery of interrupts to virtual processors without exiting to the hypervisor.
  • AMD-V (SEV) vs Intel VT-x (TDX). In the realm of trusted computing, AMD SEV (Secure Encrypted Virtualization) provides memory encryption for individual VMs, protecting data even from the hypervisor. Intel TDX (Trust Domain Extensions) technology solves the same problem, but AMD SEV, especially the SNP version, currently has a more mature and widespread ecosystem in public clouds.
  • AMD-V vs ARM Virtualization Extensions. Architecturally, ARM also introduces a new mode (Hyp mode) as the most privileged, analogous to ring -1 in x86, and uses two-stage address translation. However, ARM was originally designed for virtualization support in Armv8-A, which helped avoid many legacy x86 problems inherited by AMD-V and VT-x.

OS and driver support

AMD-V support at the operating system level is implemented through integration with the Kernel-based Virtual Machine (KVM) hypervisor and drivers such as kvm_amd. To ensure the operation of guest systems, the driver loads the sev-guest module, which creates a /dev/sev-guest character device necessary for interaction with secure virtualization functions. Platform initialization includes checking CPUID flags (function 0x8000001f) to determine support for SME and SEV technologies, as well as reading MSR registers (MSR_K8_SYSCFG and MSR_AMD64_SEV) to activate memory encryption. Additionally, the AMD IOMMU driver (AMD-Vi) configures event buffer logs (Event, PPR, GA) and interrupts, which are visible in the system as AMD-Vi<x>-[Evt/PPR/GA].

AMD-Vi (Hardware I/O virtualization)

Security

Virtualization security is ensured by hardware encryption of memory and guest machine states through SEV, SEV-ES, and SEV-SNP technologies. SEV (Secure Encrypted Virtualization) encrypts each VM’s memory with a unique key, blocking hypervisor access to its contents, while SEV-ES additionally encrypts the contents of CPU registers, preventing execution state leakage. The pinnacle of protection is SEV-SNP (Secure Nested Paging), which implements memory integrity checking via authentication tags for each page, preventing replay attacks and unauthorized page table modifications. The guest security policy is set by a bitmask at VM launch via QEMU, controlling permissions for debugging and migration.

QEMU (Emulator and hardware virtualizer of a computer)

Logging

Event logging in the AMD-V infrastructure is based on separate IOMMU hardware buffers: Event Log (registering errors and general events), PPR Log (peripheral device requests), and GA Log (guest notifications for AVIC). To prevent performance bottlenecks, support for separate interrupt vectors for each log type is implemented, allowing the kernel to process entries in parallel via named threads [Evt/PPR/GA] in x2apic mode. When processing errors and timeouts, such as hangs during suspend transitions, the driver outputs diagnostic messages (AMD-Vi) indicating the extended system capabilities (PPR, GT, IA, GA).

Limitations

A key hardware limitation is the reduction of available physical address space by one or more bits (indicated in CPUID 0x8000001f[EBX]), as the highest address bit is reserved to mark encrypted pages (C-bit). When using SEV, direct DMA accesses inside the guest system are only permitted to shared memory, while guest code pages and page tables are always forcibly marked as private. There are also limitations on nested virtualization: for example, older versions of VMware Workstation required mandatory disabling of Windows security features (VBS) based on Hyper-V, throwing the error Virtualized AMD-V/RVI is not supported on this platform, however, in version 17.x this incompatibility was resolved.

History and development

The development of AMD-V began in 2006 under the codename Pacifica as a hardware extension of the x86 instruction set to overcome the shortcomings of purely software virtualization. Unlike Intel VT-x, AMD-V initially used VMCB (Virtual Machine Control Block) data structures and Rapid Virtualization Indexing technology (RVI, formerly known as NPT) for guest system memory management. With the release of AMD EPYC processors of the Rome generation, the technology evolved from basic SME memory encryption to the comprehensive SEV-SNP confidential platform, which at the host level (with QEMU and OVMF) was fully implemented in the Ubuntu 25.04 distribution.

OVMF (UEFI Firmware for Virtual Machines)
Latest publications