Evaluate Implementation Options of KVM-based Type1 (or 1.5) Hypervisor
summary
Compares two KVM-derived designs: a minimally configured Linux+KVM hypervisor and a tiny reactive hypervisor built on VVH. Implements optimized VMCS shadowing and a lightweight nesting POC, achieving about 10x VM-exit/entry latency reduction for L2 guests by flipping a shadow bit; L2 throughput otherwise matches L1 except IO is ~90% and needs work. Notes practical problems: double scheduling, power-management and dom0/qemu plumbing for the Linux-hypervisor approach. Next steps are VVH-based lightweight hypervisor completion and IOMMU/IO virtualization pending.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:36Security Risks of Linux/KVM Guests
- 2:22Motivation of Type 1.5 Hypervisor
- 3:43Converting KVM to Type 1.5
- 4:55Two Extremes
- 9:04Domo: Scheduling and PM Issues Hypervisor needs to own VM scheduling
- 10:01Impacts of Linux/KVM Hypervisor
- 13:28Optimization for KVM Guests
- 15:11Optimized Nested Virtualization Current Implementation
- 20:26KVM L2 and LH L2 Kernel Build L2 VM Exit Breakdown
- 21:38Comparing Performance 2/2
- 22:30Findings from POCs
- 25:06Our conclusion
- 26:12Next Step
related talks
32mNotes on Taking KVM-on-KVM Nested Virtualization for a Spin
20mKVM-devirt: Extending KVM to a Zero-Overhead Partition Hypervisor
10mDemo: Nested Virtualization Acceleration
17mMitigating Excessive Pause-Loop-Exiting in VM-Agnostic KVM
24mHow Hard Could it be to Flip a bit? KVM PV Feature Enablement up the Virtualization Stack
19mKubevirt and the Cost of Containerizing VMs
11mBuild your own virtual machine with /dev/kvm and Rust!
34mThe beauty of virtual infrastructure with K8s and containers