Target Duration: 60–90 seconds (~180–220 spoken words)
Goal: Deliver a clear, plain-English overview of why the project was built, its full scope, and key mental models learned, avoiding low-level implementation minutiae while dropping strategic follow-up hooks for the interviewer.
"In this project, I built a lightweight userspace hypervisor from scratch using the Linux KVM API and hardware-assisted virtualization. The goal was to understand how a hypervisor creates, runs, and manages virtual machines directly through the Linux KVM interface.
I divided the project into three main parts:
First was VM creation and memory management. I used /dev/kvm and KVM ioctls to create virtual machines and vCPU contexts. I allocated guest memory in userspace and registered it with KVM using KVM_SET_USER_MEMORY_REGION. I also mapped the kvm_run structure, which is used to communicate VM exits between KVM and my userspace hypervisor.
Second was guest-host communication using I/O exits. I implemented a hypercall-like interface using x86 I/O ports. When the guest executed an in or out instruction on specific ports, KVM generated a KVM_EXIT_IO. My hypervisor handled these exits to exchange information, translate guest addresses to host virtual addresses, and access guest data buffers safely.
Finally, I extended the hypervisor to support multiple VMs. I implemented Producer and Consumer VMs communicating through a circular buffer. The hypervisor intercepted their I/O exits, synchronized the buffer, and used time-sliced scheduling to switch execution between the two vCPUs according to a scheduling trace.
Overall, this project gave me hands-on understanding of hardware-assisted virtualization, VM exits, guest memory management, vCPU scheduling, and inter-VM communication."
| What You Mentioned | Why It Was Done (The Motivation) | Problems Faced & How Solved (The Reality) | Target Deep-Dive Document |
|---|---|---|---|
| "VM creation & memory management via KVM API" | Understand Type-2 hypervisors & hardware-assisted virtualization (Intel VT-x / AMD-V) without QEMU bloat. | Understanding the 3-tier file descriptor hierarchy (/dev/kvm → vm_fd → vcpu_fd) and allocating backing RAM with mmap(MAP_NORESERVE). |
Topic 01: Core KVM API & Memory Layout |
| "Guest-host communication using I/O exits" | Freestanding guest code in Ring 0 cannot invoke host libc or syscalls directly; needs hypercall interface. | Solved using x86 in/out port instructions that reliably exit to userspace with KVM_EXIT_IO (unlike VMCALL which KVM handles in kernel). |
Topic 02: VM Exits & Hypercall Traps |
| "Guest-to-Host Virtual Address (GVA → HVA) Translation" | Guest pointers cannot be directly dereferenced by host userspace pointers. | Established direct 1:1 mapping in real mode: HVA = vm->mem + GVA, allowing safe pointer translation during string printing and buffer sharing. |
Topic 03: GVA→HVA Address Translation |
| "Dual-VM Producer/Consumer with Circular Buffer" | Demonstrate inter-VM memory isolation while enabling structured message passing. | VMs are completely isolated in separate 2 MB spaces; hypervisor traps notifications on I/O ports and synchronizes head/tail ring pointers. | Topic 04: Dual-VM Circular Buffer |
| "Time-sliced vCPU scheduling in userspace" | Coordinate execution between multiple independent vCPUs according to deterministic workload traces. | Alternated ioctl(vcpu_fd, KVM_RUN, 0) calls according to trace, letting hardware maintain guest register state across context switches. |
Topic 05: Userspace vCPU Scheduling |
MAP_NORESERVE? Tells the kernel not to commit swap space upfront for the 2 MB RAM; memory is allocated on-demand upon first write, enabling overcommitment.VMCALL? VMCALL is trapped by the Linux KVM kernel module for internal hypercalls and does not surface to userspace by default. in/out instructions trigger KVM_EXIT_IO which returns cleanly to userspace.struct kvm_run: Mapped with MAP_SHARED so KVM and userspace exchange exit metadata and register state with zero syscall overhead.