cs6465 Advanced OS - Lecture 02 - Virtualizability of xv6 (part 4)
Watch on YouTube →
Overview
Anton Burtsev applies the Popek and Goldberg virtualization criteria to xv6 and identifies two concrete x86 failures: `pushf` exposes real RFLAGS state, and a far jump can make xv6 misread a guest-kernel trap when the kernel runs at privilege level 1. He compares paravirtualization, full emulation, and hardware support, then explains Intel VT-x root and non-root modes, VMCS state, nested page tables, and how Linux KVM works with QEMU.
Key takeaways
- The two concrete xv6 virtualizability hazards emphasized in class are `pushf`, which can expose real RFLAGS, and a far-jump privilege assumption that fails when the guest kernel runs at privilege level 1.
- A VMM must keep the real hardware interrupt flag enabled to preserve host control, while tracking a separate guest interrupt flag to decide when guest interrupts may be delivered.
- Paravirtualization avoids some sensitive-instruction problems by modifying the guest kernel to cooperate with the hypervisor, while VT-x can support unmodified guests through hardware-managed guest state.
- Intel VT-x uses root and non-root modes plus a VMCS to save and restore guest state and control which events cause VM exits.
- Nested page tables add a VMM-controlled translation from guest physical memory to host physical memory, allowing a guest to manage its own page tables without escaping its allocated memory.
- Linux KVM and QEMU divide virtualization work: KVM handles hardware entry and exits, while QEMU can emulate devices such as disks when guest I/O traps.
Chapters
- Anton Burtsev polls the class about Friday office hours and asks students to respond to the Canvas scheduling survey.
- The lecture resumes the xv6 virtualizability analysis before moving to hardware support for virtualization.
- The Popek and Goldberg analysis identifies 17 sensitive but unprivileged instructions on the Intel Pentium as obstacles to classical virtualization.
- Burtsev focuses on instructions that matter in xv6 rather than spending equal time on obscure or unused cases.
- xv6 uses `pushf` to inspect interrupt flags, so it can observe real RFLAGS instead of a virtualized guest value.
- A far jump loads a code-segment descriptor whose privilege level may be 1 for a guest kernel, while xv6 trap handling expects privilege level 0.
- That privilege mismatch can make `trap.c` mistake a kernel fault for a user-process fault and leave the guest kernel in an inconsistent state.
- Burtsev critiques an LLM-generated explanation claiming that `IRET` silently clears a user process’s interrupt flag when returning from the guest kernel.
- The critique requires distinguishing the real hardware interrupt flag from the guest’s tracked interrupt-flag state.
- The example illustrates that a plausible explanation from an LLM still needs to be checked against x86 privilege and interrupt semantics.
- A virtual machine monitor must keep the real interrupt flag enabled so a guest cannot disable host preemption and run indefinitely.
- The VMM can track a separate guest interrupt flag and defer delivery of a timer interrupt while the guest believes interrupts are disabled.
- System calls and hardware interrupts can affect guest interrupt state differently, so direct delivery versus VMM interposition requires careful analysis.
- The practical xv6 issues identified so far are the `pushf` read of RFLAGS and the privilege-level assumption around far jumps.
- Running a guest kernel at privilege level 1 may require changing those two code paths, with further failures to be investigated if they arise.
- Burtsev leaves the possibility of a problematic interrupt-flag transition as a question for students to analyze rather than asserting a definitive answer.
- Temporarily disabling interrupts helps protect multi-step updates, such as adding a newly allocated network packet to a linked list.
- It also avoids deadlock when an interrupt handler tries to acquire a spin lock already held by code it interrupted.
- Non-maskable interrupts ignore the interrupt flag, so Linux handles them on a separate stack and constrains their lock usage.
- Paravirtualization modifies the guest kernel to cooperate with the VMM, replacing problematic operations with explicit hypervisor calls or interfaces.
- Xen used a modified Linux guest and became a high-performance virtualization platform; its paravirtualized interfaces were later incorporated into the Linux kernel.
- The approach can reduce overhead, but requires adapting guest operating systems rather than running unmodified kernels.
- The lecture places Xen alongside Denali, a University of Washington research project exploring virtual machine monitors.
- A paravirtualized kernel can explicitly notify the hypervisor when it changes state such as interrupt enablement.
- Xen’s performance and Linux integration made paravirtualization a practical alternative before hardware virtualization became widespread.
- Intel VT-x and comparable AMD and ARM features let hardware manage guest state or trap sensitive operations, reducing the need to modify guest source code.
- KVM helped make it practical to run unmodified operating systems, while nested virtualization can make repeated exits and re-entry across VM layers expensive.
- Paravirtualization remains useful in nested setups where reducing that transition overhead matters; secure VM designs can also encrypt guest memory beyond the hypervisor’s view.
- Full emulation decodes each guest instruction in software, updates virtual registers and instruction pointers, and can even run ARM guests on x86 hosts.
- JSLinux, built by Fabrice Bellard, demonstrates Linux and Windows 2000 running through a software emulator in a browser, though emulation is slower than native execution.
- VMware’s early approach ran guest user code on hardware while emulating guest-kernel instructions, using just-in-time translation and cached code to improve speed.
- VMware’s binary-translation approach and Xen’s paravirtualization represent different ways to handle guest-kernel instructions that are not safely virtualizable.
- Intel VT-x introduces root mode for the VMM and non-root mode for the guest, with the guest retaining its own privilege levels.
- A VMCS, or Virtual Machine Control Structure, stores guest and host state and controls transitions between the two modes.
- On VM entry, the processor loads guest registers and state from the VMCS; on VM exit, it saves guest state there and resumes the VMM.
- VM-exit controls determine whether events such as interrupts, `HLT`, or `RDTSC` trap to the VMM or run within the guest.
- VMCS configuration includes interconnected state and control fields, so a hypervisor must verify details rather than trust generated code or an LLM explanation.
- A guest uses its own page tables to translate guest virtual addresses into guest physical addresses, but those addresses still need mapping into host physical memory.
- Nested page tables, controlled by the VMM, perform the guest-physical-to-host-physical translation while the guest retains its own CR3 and page tables.
- The VMM uses those mappings to confine guest memory to the physical pages allocated to that virtual machine.
- KVM is a Linux kernel module that configures the VMCS and enters the guest; QEMU runs as a user process and provides guest memory and device emulation.
- When a guest operation such as an emulated disk-port access causes a VM exit, KVM returns control to QEMU, which can implement the device behavior and resume the guest.
- The planned xv6 assignment follows this structure: add a small KVM-style extension, launch a second xv6 instance with VT-x, then build toward device emulation.
Transcript excerpt
0:18 Okay, let's uh get going. So, uh I leaked accidentally, but so let's quickly discuss the the possible time for the for the for the office hours. Me open it up. >> [sighs] >> This is it. Friday at 4. Is that the best time? Will it work for for most? Oh, you only have like five answers, guys. like maybe answer a little otherwise he will I mean I can do two half an hour slots uh during the
1:07 week or something like that but uh do you need this link again it's was sent through the through canvas I mean office hours will be helpful especially when you start working in homeworks Friday is not the best day because uh there's always something in Right. But uh but we can we can work in but please answer that that was the point essentially. Okay sir. No actually I didn't look it because I did not enable screen sharing which is good on its own as well. Okay cool. So let's go back to this lecture and finish u and then move into move into hardware support for virtualization. Sure.
1:59 Okay. So, just to remind you where we were last time. So, and it's it's an interesting example, but let me So, just just a quick reminder where what we were doing last time. So we're still looking at this paper by Robin and Irvin and uh what uh what they say they say look there are 17 they did analysis of all whatever 200 something instructions of Intel Pentium machine and they said okay there are like this 17 sensitive but not privileged instructions right which kind of breaks virtualiz virtualizability of x86 architecture
2:45 and what we're doing here we said okay look we're kind of looking at all of
This is the start of the transcript. Save this video free for the whole transcript, searchable and time-coded.
In this course
Related notes
Summary, takeaways, and chapters were generated by AI from the video's transcript and may contain errors. The video belongs to its creator, Anton Burtsev.