2. 嵌入式虚拟化基础

在嵌入式KVM平台的部署与调试中，虚拟化基础决定了后续所有问题的分析路径。嵌入式设备资源受限、外设固定、实时性要求高，因此理解虚拟化如何“隔离”与“复用”硬件，比单纯记住命令更重要。本节从虚拟化原理出发，对比两类Hypervisor，再落到KVM的架构与内核模块组成，为后续部署与排障建立模型。

一、虚拟化原理：特权级、陷入与模拟

虚拟化的核心目标，是让多个客户机（Guest）共享同一套物理硬件，同时彼此隔离。CPU通常提供多个特权级，操作系统内核运行在最高特权级，用户程序运行在较低特权级。虚拟化层（Hypervisor/VMM）需要把客户机内核的敏感指令“截获”并代为执行，这一过程称为陷入与模拟（trap-and-emulate）。

在ARM架构中，通常通过异常级别EL0～EL3实现隔离：EL0运行用户程序，EL1运行客户机内核，EL2运行Hypervisor，EL3用于安全监控。当客户机执行敏感操作（如访问页表基址、配置中断控制器、执行WFI）时，会触发异常陷入EL2，由Hypervisor决定是模拟、转发还是直接执行。内存方面，通过两阶段地址转换（Stage-1由客户机控制虚拟地址到中间物理地址，Stage-2由Hypervisor控制中间物理地址到真实物理地址）实现隔离；设备方面，则通过设备树裁剪、MMIO陷入或直通（passthrough）来分配。

二、Type-1与Type-2 Hypervisor的区别

按Hypervisor所处位置，可分为Type-1（裸机型）和Type-2（宿主型）。Type-1直接运行在硬件之上，自身承担资源调度，客户机运行在其上；Type-2运行在通用操作系统之上，依赖宿主OS提供驱动与调度。嵌入式KVM属于Type-1思路：Linux内核通过KVM模块将自身“改造”为Hypervisor，客户机作为普通进程被调度。

需要澄清一个常见误区：KVM本身不是完整的Type-1 Hypervisor，而是Linux内核中的一个模块，使Linux成为Hypervisor。它借助Linux的调度、内存管理和驱动框架，因此兼具Type-1的性能与Linux生态的便利。在嵌入式平台上，这种“Linux即Hypervisor”的形态非常常见。

三、KVM架构与内核模块组成

KVM的整体架构可分为用户态与内核态两部分。用户态由QEMU等VMM负责设备模拟、虚拟机生命周期管理；内核态由KVM模块负责CPU虚拟化、内存虚拟化和中断注入。两者通过ioctl接口交互：QEMU创建虚拟机（KVM_CREATE_VM）、创建vCPU（KVM_CREATE_VCPU），再通过KVM_RUN进入客户机执行，遇到敏感操作时返回用户态处理。

内核模块方面，最核心的是kvm.ko与架构相关的kvm-arm.ko（x86平台为kvm-intel.ko或kvm-amd.ko）。在ARM64嵌入式平台，还需要关注VGIC（虚拟中断控制器）与虚拟定时器的支持。加载后可通过以下命令确认：

# 查看 KVM 模块是否加载
lsmod | grep kvm
# 典型输出
kvm_arm                94208  0
kvm                   733184  1 kvm_arm

# 查看 CPU 是否支持虚拟化扩展
dmesg | grep -i kvm
# 典型输出
kvm [1]: Hyp mode initialized successfully
kvm [1]: virtual timer IRQ 25
kvm [1]: IPA Size Limit: 40 bits

四、案例与排障：从架构定位问题

某嵌入式网关项目在KVM上运行一个实时客户机，出现客户机启动后串口无输出。按架构分层排查：先确认kvm_arm已加载且Hyp模式初始化成功；再检查QEMU命令行是否将串口以virtio或MMIO方式暴露；最后查看客户机设备树是否包含对应节点。最终发现是Stage-2页表未映射串口MMIO区域，导致客户机访问时陷入后未被正确模拟。修复方式是在QEMU中补充-serial参数并确认设备树匹配。

复盘要点：嵌入式KVM问题大多可归入三类——CPU虚拟化（异常级别、陷入处理）、内存虚拟化（Stage-2映射、IPA范围）、I/O虚拟化（中断注入、MMIO模拟、直通配置）。掌握本节架构图，就能在后续部署与调试中快速判断问题落在哪一层，而不是盲目修改配置。