Multi-KVM Abstract
summary
Proposal builds a way to run multiple independent KVM modules on one host so you can upgrade or A/B test KVM without unloading the old module. It privatizes KVM internals, collapses kvm_intel/kvm_amd into kvm.ko on x86, and extracts shared system state (ASID/BPID, perf callbacks, MSR handling) into a small base module called VAC so those singletons stay stable. Multi‑KVM is opt‑in and backward compatible; live kernel upgrades remain out of scope so true zero‑downtime isn’t promised.
AI-written summary · about
chapters (15)
- 0:00Introduction and presenter
- 0:42Why multi-KVM is proposed
- 1:24How multi-KVM would work
- 3:34Feedback and discussion points
- 6:25Live update vs feature rollout
- 11:27Testing different KVM flavors
- 12:53Isolation of KVM internals
- 15:27Prior art and other kernel modules
- 16:30Architecture-specific considerations
- 18:17PowerPC and module separation
- 20:02Security and trust boundaries
- 22:09Address space isolation
- 23:54Security fixes and live patching
- 25:46Upstream acceptance criteria
- 26:10Wrap-up and next steps
related talks
31mKVM Nested Virtualization: Workings and Usecases
50mMultikernel Architecture: Kernel-to-Kernel Isolation and Resource Management
38mPanel Discussion: KVM-based Virtualization Contributor Q&A
21mEmulating Hyper-V in 2022
32mIntroduce Virtualization and Kernel Infrastructure to Newbies
39mKVM Modifications for Clustered Operation
30mAIA Virtualization in KVM RISC-V
50mPanel Discussion: KVM-based Virtualization Contributor Q&A