虚拟化中Hypervisor的工作原理、系统调用需求及运行模式问询
Great question—let's break this down clearly, since hypervisors are the unsung heroes of virtualization and their behavior varies a lot based on their type.
First, we need to split hypervisors into two core categories, because their underlying mechanisms are night and day:
Type 1 (Bare-Metal) Hypervisors
These run directly on the host hardware, acting as the "primary OS" for the physical machine. Think VMware ESXi, Xen, or KVM (the kernel module part paired with QEMU).
- Resource Management: They take full control of CPU, memory, storage, and network hardware right out the gate. They slice these physical resources into isolated "virtual pools" assigned to each virtual machine (VM).
- Privilege Instruction Handling: When a VM tries to execute a privileged instruction (like accessing hardware registers), the CPU's virtualization extensions (Intel VT-x, AMD-V) trap this instruction and pass it to the hypervisor. The hypervisor either simulates the instruction's effect or directly routes it to the physical hardware (if safe) to maintain VM isolation and performance.
- Isolation: Each VM runs in its own isolated execution environment, so a crash or misbehavior in one VM doesn't affect others or the hypervisor itself.
Type 2 (Hosted) Hypervisors
These run on top of an existing host operating system (like Windows or Linux), relying on the host OS for low-level hardware management. Examples include VirtualBox, VMware Workstation, or Parallels Desktop.
- Layered Execution: The hypervisor sits between the VM and the host OS. When a VM needs to access hardware, the hypervisor forwards the request to the host OS, which then handles the actual hardware interaction.
- Flexibility: Since they piggyback on a host OS, they're easier to install and use for end-users, but they add a layer of overhead compared to Type 1.
Short answer: It depends entirely on the hypervisor type.
- Type 1 Hypervisors: No, they don't rely on system calls from a host OS. Since they run directly on hardware, they have direct access to all hardware resources and implement their own low-level routines to manage them. The only "calls" they use are internal ones for their own components (like logging or management interfaces)—not standard OS system calls.
- Type 2 Hypervisors: Yes, absolutely. They can't access hardware directly. Any time a Type 2 hypervisor needs to allocate memory, read/write to disk, or send network traffic, it has to invoke system calls from the underlying host OS to get those tasks done. For example, VirtualBox's user-space manager uses the host's
mmap()system call to allocate memory for VMs, and its kernel module uses host OS APIs to interact with CPU virtualization extensions.
Again, this splits along Type 1/Type 2 lines, with some nuance:
- Type 1 Hypervisors: Almost entirely run in the highest privilege level (kernel/Ring 0 on x86). This is non-negotiable—they need direct access to hardware and the ability to trap VM privilege instructions, which can't be done from user space. Some Type 1 hypervisors do have lightweight user-space components (like ESXi's web management interface), but the core virtualization logic, resource management, and instruction handling all live in kernel mode.
- Type 2 Hypervisors: Use a hybrid model:
- Kernel Mode: The core critical components (like instruction trapping, virtual CPU management, and hardware access mediation) run in the host OS's kernel mode. For example, VirtualBox's
vboxdrvkernel module runs in Ring 0 to efficiently handle VM-to-hardware requests. - User Mode: Non-critical parts like VM configuration, user interfaces, and some peripheral simulation run in user space. This makes them easier to update and safer—if a user-space component crashes, it won't take down the host OS or other VMs.
- Kernel Mode: The core critical components (like instruction trapping, virtual CPU management, and hardware access mediation) run in the host OS's kernel mode. For example, VirtualBox's
As a concrete example: KVM (a Type 1 hypervisor) is a Linux kernel module, so it runs in Ring 0. QEMU, which works with KVM to simulate peripherals, runs in user space. Together, they create a hybrid Type 1 setup with both kernel and user mode components.
内容的提问来源于stack exchange,提问作者Daniel G

