Do VMMs use Virtual Memory on the hosts?

Question

I am trying to understand how virtualization was performed in the past using shadow page tables. The articles I've read all talk about about the translation from Guest Virtual Memory to Host Physical Memory. I understand how the Shadow Page tables eliminate the need for a Guest Virtual to Guest Physical Translation. My question is, what happened to the Host Virtual to Host Physical step. (HVA --> HPA).

Do the Virtual Machine Managers in the cited articles, not use virtual memory in the host at all? Are they assumed to have direct access to the Physical memory of the host system? Is it even possible? I thought the TLB cache translation is implemented in hardware by the MMU and and every instruction's addresses are translated from virtual to physical by the MMU itself. But then again, I am not sure how kernel code works with TLB? Do kernel instructions not go through TLB?

Answer 1

I am not sure if I got your point accurately, I'm trying my best to answer your question.

There is no need for HVA->HPA because what guest wants is HPA instead of HVA. Which means HVA is useless for a guest accessing its guest memory region.

So the transfer flow you expected might be without considering shadow page table may be:

GVA -> GPA -> HVA -> HPA

But as most hypervisors are running in kernel mode, who knows how the host's and guest's memory is allocated, so it can map GPA to HPA directly and eliminate the need of HVA:

GVA -> GPA -> HPA

This guest memory translation flow is nothing related to the userspace of hyperviosr, whose flow is HVA -> HPA.

Not sure if above answers your question.

Answer 2

The answer can be yes or no. If yes, the hypervisor maps guest RAM into virtual memory on the host, so the host may swap it in and out of host RAM. If no, the hypervisor maps guest RAM into locked physical memory on the host.

VirtualBox is in the no group. VirtualBox runs a device driver in the host kernel, and uses this driver to allocate locked memory for guest RAM. Each page of guest RAM stays resident at a fixed host physical address, so the host can never swap out the page. Because of this, guest RAM must be smaller than host RAM. VirtualBox's manual says to spare at least 256 MB to 512 MB for the host.

The MMU can only map virtual addresses to physical addresses. In VirtualBox, the guest has an emulated MMU to map guest virtual addresses to guest physical addresses. VirtualBox has its own map of guest physical addresses to host physical addresses, and uses the host MMU to map guest virtual addresses to host physical addresses. Because of locked memory, the host physical addresses never become invalid.

Mac-on-Linux is in the yes group. I once used it to run a guest Mac OS 9 inside a host PowerPC Linux. I gave 256 MB of RAM to Mac OS 9, but my real Linux machine had only 64 MB of RAM. This worked because MOL maps guest RAM into host virtual memory, with an ordinary mmap() call in a user process. MOL then uses a Linux kernel module to control the host MMU.

But the host MMU can only map to host physical addresses, not virtual ones. The guest has an emulated MMU that maps guest virtual to guest physical. MOL adds a base address to translate guest physical to host virtual. MOL's kernel module uses the host map to translate host virtual to host physical, then uses the host MMU to map guest virtual to host physical.

If Linux swaps out a page of guest RAM, then the host physical address becomes invalid, and the guest system might overwrite someone else's memory and crash the host. There must be some way to notify MOL that Linux has swapped out the page. MOL solved this problem by patching an internal Linux kernel function named flush_map_page or flush_map_pages.

KVM is also in the yes group. Linux added a kernel feature called memory management notifiers to support KVM. When QEMU uses KVM for virtualization, it allocates guest RAM in host virtual memory. The MMU notifier tells KVM when the host is swapping out a page.