A process inside a virtual machine loads from virtual address 0x7abc.

The guest operating system handles this address as it would on a physical computer. Its page tables map the process's virtual page to what the guest believes is a physical page.

But that “physical” page cannot be an unrestricted address in the host's real memory. Another VM may use the same number, and the host must remain free to place or move each VM's data independently.

Machine virtualization therefore adds another translation:

A guest virtual address becomes a guest physical address through the guest page tables, and that becomes a host physical address through a hypervisor-controlled translation.

The guest kernel controls the first mapping. The hypervisor controls the second. Hardware composes them so ordinary guest instructions ultimately reach memory assigned to the correct VM.

Virtualized memory gives the guest kernel a physical address space of its own, then maps that guest physical space onto host memory under hypervisor control.

This extra level preserves the guest operating system's normal memory-management role without allowing it to address arbitrary host RAM.

Memory virtualization introduces three terms that must remain distinct.

A guest virtual address, or GVA, is an address generated while software runs inside a VM. For a guest application, it is an ordinary process virtual address. Guest-kernel code also executes through guest virtual mappings.

A guest physical address, or GPA, is the result of the guest's address translation. The guest kernel treats this as a machine address and assigns guest physical page frames to its processes.

A host physical address, or HPA, identifies a location in the physical address space controlled by the host. This is the address that ultimately reaches the host's cache and memory system.

The word physical in guest physical address describes the interface exposed to the guest. It does not mean the number directly selects a host RAM location.

Two VMs can therefore use GPA 0x120000 safely. The active VM's second-stage translation context determines whether that number reaches the host page holding VM A's data or a different host page holding VM B's data.

An operating-system kernel expects to manage memory for its processes. It creates page tables, chooses which physical frames back virtual regions, changes permissions, handles page faults, and reclaims pages.

Removing all of that responsibility would require a substantially different guest operating system. Machine virtualization instead preserves the interface the kernel expects: a numbered physical address space containing RAM and device regions.

Suppose a VM is configured with 8 GiB of memory. Its guest kernel may see a physical layout resembling:

Only the guest-usable region is ordinary memory. The guest kernel has to learn this layout from firmware rather than assuming every address is RAM.

The guest kernel builds its own understanding of that layout and allocates guest physical frames from the regions marked as RAM.

The hypervisor must retain a separate view. It decides which host resources implement those guest physical ranges. Some GPAs correspond to host-backed RAM, some identify virtual-device interfaces, and some are intentionally invalid.

This separation lets the guest perform ordinary memory management while the hypervisor enforces VM boundaries. The guest kernel decides which GPA should back a guest virtual page; the hypervisor decides which host resource may implement that GPA.

If the guest could choose host physical addresses directly, a malicious or faulty guest kernel could map pages belonging to the host or another VM. The second stage prevents that.

Assume a system uses 4 KiB pages. A 4 KiB page has a 12-bit byte offset because 4 KiB equals 4096, or 2¹², bytes.

Suppose a guest instruction reads from GVA 0x7abc. The guest virtual page number is 0x7, and the offset within that page is 0xabc.

The guest's page tables map guest virtual page 0x7 to guest physical frame 0x120. Stage 1 therefore produces:

The hypervisor's second-stage tables map guest physical frame 0x120 to host physical frame 0x9c0. Stage 2 produces:

The complete path is:

The offset abc survives both stages. The guest controls the first translation and the hypervisor controls the second, and the guest cannot influence the second at all.

The page offset remains 0xabc through both stages. Translation changes the page-frame portion of the address, not the byte's position within the page.

The guest kernel knows that guest virtual page 0x7 maps to guest physical frame 0x120. It does not need to know that frame 0x120 currently reaches host frame 0x9c0. The hypervisor can change the second mapping while preserving the guest's view.

Modern processors can apply both translation stages in hardware while a guest runs.

Intel calls its second-stage mechanism Extended Page Tables, or EPT. AMD uses Nested Page Tables, or NPT. Arm documentation commonly calls the mechanism stage 2 translation.

The names differ, but the division of responsibility is the same. Stage 1 tables are selected and managed by the guest kernel; stage 2 tables are selected and controlled by the hypervisor.

When a vCPU runs, the hypervisor configures a second-stage translation context belonging to that VM. The guest can switch between its processes' stage 1 page tables, just as a native operating system would, but those mappings still produce GPAs confined by the active stage 2 context.

The hardware must also read the guest's page-table entries during a page walk. Those page tables themselves reside in guest physical memory, so the processor uses stage 2 translation to reach them in host memory.

Conceptually, a translation miss can require work such as:

Every step of the guest's own walk needs a second-stage translation of its own, which is why nested paging multiplies the cost of a miss.

This can require more memory accesses than a page-table walk without virtualization. Processors cache recent translation results in the TLB and related page-walk caches so successful accesses do not repeat the full walk every time.

The TLB can effectively remember the composed result from a GVA to an HPA, together with the relevant permissions and address-space context. The two-stage model still defines correctness even when caches make the common path much faster.

Address translation also enforces access permissions.

The guest uses stage 1 permissions to isolate its own processes and protect its kernel. A guest page-table entry might allow a user-mode read while rejecting writes or instruction execution.

The hypervisor uses stage 2 permissions to constrain the entire VM. A GPA can be backed as read-only, executable, writable, or inaccessible according to the platform's needs.

An access succeeds only if both stages permit it. Its effective permission is the intersection of the stage 1 and stage 2 permissions.

Suppose a guest maps a virtual page as readable and writable, but the second-stage entry allows only reads. A guest load succeeds because both stages allow it. A guest store is blocked because stage 2 denies the write.

The guest cannot expand its host authority by editing its own page tables. It can map any GPA the virtual platform allows it to use, but the second stage still decides whether that GPA has a valid host mapping and which operations are permitted.

This is the memory-isolation boundary between VMs. Guest page tables protect subjects inside one VM; second-stage tables protect host memory and other VMs from that guest.

Two translation stages create two different kinds of failure.

A guest page fault

A guest page fault occurs when stage 1 cannot complete the requested access. The guest virtual address may be unmapped, or the guest page-table permissions may reject the operation.

The processor normally delivers this fault to the guest kernel. The guest kernel can allocate a guest page, load data, change its page table, terminate the guest process, or take another action allowed by its own memory-management policy.

The hypervisor does not need to treat every guest page fault as a host error. From the VM's point of view, page faults are normal operating-system events.

A second-stage fault

A second-stage fault occurs after guest translation produces a GPA that the current second-stage mapping cannot service with the requested permission.

This event transfers control to the hypervisor. On Intel EPT, it is commonly reported as an EPT violation. AMD and Arm use architecture-specific terms for comparable events.

The hypervisor examines the GPA and the access. Depending on the mapping, it may:

The distinction can be summarized as:

Both events arise during memory access, but they belong to different protection domains and are handled by different control layers.

Second-stage hardware support was not always available. A hypervisor could instead maintain shadow page tables that map guest virtual addresses directly to host physical addresses.

The guest would still modify what it believed were its page tables. The hypervisor would monitor those changes and update a separate hardware-visible shadow mapping from GVA directly to HPA, reflecting the guest's intended GVA-to-GPA mapping.

This approach requires the hypervisor to keep the shadow state consistent with guest page-table changes. It may write-protect guest page tables, trap attempts to modify them, validate the new entries, and update corresponding shadow entries.

Shadow paging can run operating systems that were not designed for virtualization, but frequent page-table changes can produce substantial exit and synchronization overhead.

Hardware second-stage translation changes the division of work. The guest's own page tables can remain directly meaningful to the processor, while a separate hypervisor-controlled stage confines their results. Shadow techniques still matter in some implementations and compatibility paths, but nested hardware translation is the normal model for modern server virtualization.

In a QEMU/KVM virtual machine, guest RAM is commonly represented by memory mapped into the QEMU process's host virtual address space.

QEMU tells KVM that a range of GPAs is backed by a range of host virtual addresses. KVM records this association as a memory slot and uses the host kernel's memory mappings to establish the second-stage translations needed by guest execution.

The QEMU host virtual address is useful to the host software managing the VM. Once hardware translations are established, it is not necessarily an additional software lookup performed for every successful guest load or store.

The host kernel can back different portions of QEMU's virtual range with physical pages located throughout RAM. A guest may see 8 GiB of contiguous guest physical memory even though its host pages are not physically adjacent.

This creates four address terms in a KVM implementation:

The fundamental hardware execution path remains GVA to GPA to HPA. HVA explains how user-space VMM software and the host kernel manage the backing memory.

Suppose a VM is configured with 16 GiB of guest memory. That number defines the guest physical memory made available by the platform. It does not, by itself, answer three other questions:

The answers depend on the platform's allocation policy and the workload.

Some environments reserve or preallocate the configured memory. Others establish host backing as guest pages are touched. Pages can also be shared, swapped, pinned for devices, or accounted with platform-specific rules.

Inside the VM, the guest kernel tracks which guest physical pages it considers free or used. The host sees backing pages belonging to the VM process; it does not automatically understand which application owns each byte or whether a guest page contains reusable data.

This creates several different quantities:

These values can differ significantly. Treating any one of them as “the VM's memory usage” without naming the measurement leads to misleading capacity and performance conclusions.

A host overcommits memory when the total configured memory of its VMs exceeds the physical capacity it can supply simultaneously.

For example:

This can work when the VMs do not all need their full allocations at once. It improves utilization in the same way that CPU overcommitment can work when vCPUs are often idle.

Memory differs from CPU time in an important way. A vCPU can wait and run later. A memory page that a workload actively needs must have contents available somewhere. If combined working sets approach or exceed physical RAM, the host must reclaim memory, move contents to slower storage, request guest cooperation, or fail allocations.

The result can be severe latency even when each guest believes its own memory configuration is adequate.

Overcommitment is therefore a capacity promise based on expected simultaneous demand. It is safe only while the host has a viable plan for the workloads' actual working sets.

The host cannot safely discard a guest page merely because it looks unused from outside. The bytes might hold live kernel data, an application heap, or file cache that the guest expects to retain.

A balloon driver provides a cooperative reclaim mechanism.

To reduce the guest's usable memory, the host asks the balloon driver inside the VM to inflate. The driver allocates guest physical pages so the guest kernel stops giving them to ordinary workloads. It then identifies those pages to the hypervisor, which can release or reuse their host backing.

Inflating the balloon makes the guest driver claim guest physical pages, the guest kernel treats those pages as unavailable, and the host reclaims their backing.

To return capacity, the balloon deflates. The host restores backing as required, and the driver releases pages to the guest kernel.

The terminology can feel backward: a larger balloon means less memory for guest applications because the balloon occupies more of the guest's physical space.

Ballooning does not make reclaim free. The guest may evict file cache, swap its own pages, or terminate applications if the remaining memory is insufficient. It simply lets the guest kernel participate rather than having the host blindly remove memory.

Balloon statistics also depend on a working guest driver. Without guest cooperation, the host has less semantic information about which pages are cheapest to reclaim.

Memory pressure can be handled at either level.

With guest swapping, the guest kernel selects guest pages and writes their contents to the guest's virtual swap device. The guest knows which processes and pages it is reclaiming, but the I/O ultimately travels through the virtual storage path.

With host swapping, the host treats VM backing like other host memory and moves host pages to host swap. The guest may still believe those pages are resident RAM.

Host swapping hides the decision from the guest but can create unpredictable pauses when a vCPU accesses an evicted page. The host must restore the page before guest execution can continue.

The two levels can interact badly. The host might swap out a page that contains guest swap cache or page-table data, while the guest independently performs its own reclamation. This duplicated work is sometimes called double paging.

Sustained host swapping is usually a sign that resident working sets exceed available RAM. It preserves correctness longer than simply discarding pages, but storage latency makes it a poor substitute for adequate memory capacity.

Two-stage translation adds potential page-walk work, but the cost is not paid in full on every memory reference. Translation caches make most accesses use recently resolved mappings.

Workloads can still expose several costs:

Translation misses are more expensive because walking guest page tables also requires translating the GPAs of the page-table pages.

Frequent mapping changes can invalidate cached translations and require the processor or hypervisor to rebuild them.

Large working sets can exceed translation-cache capacity, increasing page walks even when ordinary data still fits in RAM.

Host memory pressure can remove backing pages from RAM, turning an otherwise ordinary guest access into a slow host fault.

Larger page mappings can reduce the number of translations needed to cover a given amount of memory. A guest may use huge pages in stage 1, and the host can use large mappings in stage 2 when alignment and physical backing permit it.

Huge pages do not remove the two stages. They let each stage cover more bytes with fewer entries, which can reduce TLB pressure and page-walk overhead. They also require larger contiguous units and can increase allocation difficulty or wasted space.

On a NUMA host, a physical CPU accesses some memory regions faster than others. Virtualization hides the exact host layout, but it does not remove this hardware behavior.

Suppose a VM's vCPUs run primarily on host NUMA node 0 while most of its backing pages reside on node 1. Frequent remote accesses can make the guest observe higher memory latency without knowing the complete physical reason.

A hypervisor or VM manager can align vCPU placement and memory allocation to improve locality. For large VMs, it may also expose a virtual NUMA topology so the guest can make its own placement decisions.

Pinning memory and vCPUs can improve predictability, but it reduces placement flexibility. The operator must balance locality, failover requirements, host utilization, and the needs of other VMs.

A physical device can transfer data directly to memory using DMA. If a device is passed through to a guest, the guest driver supplies addresses for its I/O buffers.

Those guest-provided addresses must not let the device write into arbitrary host memory.

An I/O memory management unit, or IOMMU, translates and checks device DMA addresses in a role similar to the CPU's MMU. The host configures mappings that confine the assigned device to memory belonging to the VM.

Without this protection, a device controlled by a guest could bypass CPU page tables and corrupt the hypervisor or another VM through DMA.

Device passthrough therefore depends on both CPU-side memory isolation and IOMMU configuration. The guest may operate the device directly, but the host still defines the memory boundary around it.

Consider a database VM configured with 16 GiB of memory. Inside the guest:

The guest appears healthy. Its working set fits, it has useful file cache, and it is not swapping.

Now suppose the host runs several similar VMs whose working sets grow at the same time. Physical RAM becomes scarce. The host begins swapping VM backing pages.

From the database's perspective, a memory load that normally completes from RAM can suddenly stall while the host restores a page from storage. Guest metrics may show no guest swap I/O because the guest did not make the eviction decision.

If ballooning is used instead, the guest sees its usable capacity shrink. It can reclaim file cache or choose which of its own pages to swap, but its database may still slow if the new working set no longer fits.

This creates a practical diagnostic rule:

Memory health inside the guest and memory pressure on the host are different measurements.

When a VM experiences unexplained latency, both layers matter: guest working-set behavior, guest faults and swap, host residency, host faults and swap, balloon state, and physical NUMA placement.

Inside a Linux guest, free reports the guest kernel's view:

MemTotal describes memory made available to the guest kernel, after any guest-reserved regions. It does not reveal the VM's exact host residency or the host's free RAM.

On a libvirt-managed host, dominfo shows the VM's configured and current memory:

Relevant output can include:

Here, Used memory commonly means the current memory allocation presented to the domain. It should not automatically be interpreted as the application's working set or the VM process's resident set.

More statistics may be available through:

Example fields include:

The values are in KiB. actual is the current balloon allocation, while unused and usable describe guest-visible state reported through the balloon mechanism. rss is host-side resident memory associated with the domain process. Available fields depend on the hypervisor, guest driver, and statistics configuration.

On a KVM host, second-stage support may be visible through a module parameter:

or:

The path exists only when the corresponding module is loaded, and the output format is kernel-specific. These values indicate whether KVM is using the processor's nested translation feature; they do not describe an individual VM's memory pressure.

No single number answers every memory question. Always identify whether a metric describes guest configuration, guest usage, host residency, or active working set.

Second-stage translation prevents a guest from reaching arbitrary host memory merely by installing a page-table entry. Even guest root can only map GPAs that the hypervisor makes valid for that VM.

The hypervisor remains more privileged than the guest. Host administrators and sufficiently privileged management software may be able to inspect, copy, or alter guest memory. Address translation isolates guests from one another; it does not hide a guest's memory from the platform that implements it.

When a host page is reassigned between security domains, the platform must prevent the new owner from reading stale data left by the previous one. Hypervisors and host kernels clear or otherwise safely initialize pages before exposing them as fresh guest memory.

Some platforms intentionally share identical read-only contents between VMs to save memory and create a private copy if one guest writes. This can improve density, but sharing across trust boundaries requires care because it changes timing and information-sharing behavior.

The second-stage mapping is therefore both a placement mechanism and a security mechanism. Its correctness is essential to the VM boundary.

Memory virtualization adds a second address-translation stage. Guest page tables map guest virtual addresses to guest physical addresses; hypervisor-controlled tables map guest physical addresses to host physical addresses.

The separation lets an ordinary guest kernel manage memory for its processes while preventing it from addressing the host or another VM. Stage 1 faults belong to the guest kernel, while second-stage faults belong to the hypervisor.

Hardware mechanisms such as EPT, NPT, and Arm stage 2 translation perform the nested mapping efficiently. Translation caches, large pages, and NUMA-aware placement reduce performance costs, while an IOMMU extends comparable isolation to device DMA.

Configured guest memory, host-resident memory, guest usage, and working set are different measurements. Overcommitment, ballooning, guest swap, and host swap change those values in different ways and can create latency that is visible at only one layer.

The central mental model is:

The guest controls virtual-to-guest-physical mappings; the hypervisor controls every path from guest physical memory to the host.