QEMU启动慢、内存开销大但兼容性最强；Cloud Hypervisor轻量快速但仅支持Linux 5.10+及特定内核配置；Firecracker最快最省资源但网络存储配置复杂。
QEMU 启动慢、内存开销大，但兼容性最稳
用 qemu-system-x86_64 跑 Kata Containers 时，你会明显感觉到容器启动要等 1–2 秒，ps aux 里能看到多个 qemu-system-x86_64 进程，每个默认吃掉 100MB+ RSS。这不是配置错了，是 QEMU 本身带完整设备模拟（PCI、USB、VGA），哪怕你只跑一个 busybox 容器也得加载整套 BIOS 和固件。
适合场景：需要运行老内核、非标准驱动（比如某些 DPDK 网卡）、或必须支持 kvm_intel + vhost_net 组合的生产环境；Kata 的 runtime_type = "qemu" 模式下，default_kernel_params 里加 console=ttyS0 才能正常串口日志输出，漏了就卡在 “Starting kernel ...”。
- 别关
CONFIG_KVM—— Firecracker 和 Cloud Hypervisor 都依赖它，QEMU 却还能 fallback 到 TCG（极慢） -
qemu.conf中设enable_kvm = true，否则性能跌 5 倍以上 - 禁用图形输出：
qemu_args = "-nographic -vga none -device virtio-rng-pci"，少几个设备就少几毫秒延迟
Cloud Hypervisor 内存精简、启动快，但只支持 Linux 5.10+
cloud-hypervisor 是 Rust 写的轻量级 VMM，没 BIOS、没 legacy 设备，靠 virtio-devices 直通，所以启动快（~300ms）、内存常驻仅 30–50MB。但它不支持 acpi=off，也不认老内核的 vmlinux，你用 Kata 自带的 kata-vmlinuz-*.bin 没问题，但换自己编译的 5.4 内核就会报 Failed to boot kernel: Invalid ELF header。
典型错误现象：kata-runtime exec 报 failed to create VM: Failed to boot kernel，其实不是路径错，是内核没启用 CONFIG_VIRTIO_PCI 或 CONFIG_VIRTIO_BALLOON —— Cloud Hypervisor 强制要求这些。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 必须用
vmlinux格式内核（不是zImage），且需CONFIG_ACPI=y -
kernel_params = "console=ttyS0,115200n8 systemd.unified_cgroup_hierarchy=1"—— 少systemd.unified_cgroup_hierarchy=1会导致 cgroup v2 下进程无法调度 - 不支持热插拔 CPU，
cpu_count = 2写死就完事，动态扩缩容得重启 pod
Firecracker 启动最快、隔离最强，但网络和存储配置反直觉
firecracker 启动只要 ~100ms，内存压到 5–10MB，靠 microVM 架构砍掉所有非必要组件。但它没有传统 PCI 总线，网卡和块设备全靠 virtio-net 和 virtio-block 用户态实现，这意味着：宿主机上看不到 veth 对端自动配好，tap 设备得手动 up，否则容器 ping 不通外网。
常见错误：kata-runtime run 成功，但 ip a 在容器里只看到 lo，dmesg 里有 virtio_net: probe of 0000:00:02.0 failed with error -2 —— 其实是 Firecracker 启动时传的 net = [...] JSON 里 iface_id 和宿主机 tap 名字不一致，或者没执行 ip link set tap0 up。
- 块设备镜像必须是 raw 格式，qcow2 会直接 panic，报
Failed to parse block device configuration - 网络配置必须显式指定
host_dev_name（如tap0），且该设备需提前创建并 up，Firecracker 不帮你做 - 不支持
virtio-fs，共享目录只能走 9p（性能差）或 bind mount（绕过 VM 隔离）
选型不能只看 benchmark，得盯住你的 workload 类型
如果跑的是 Java 微服务，冷启动敏感，又不需要 hostPath 挂载大文件，Firecracker 是最优解；但如果跑的是数据库中间件（比如 TiDB Proxy），要调 memlock、绑核、用 hugepages，就得选 QEMU —— Cloud Hypervisor 目前还不支持 memlock 限制透传，Firecracker 更是压根没暴露这个接口。
还有个隐形坑：Kata 的 configuration.toml 里三个后端共用同一份 [hypervisor.qemu] 配置节，你以为改了 [hypervisor.cloud_hypervisor] 就生效？其实得清掉 /run/vc/sbs/ 下残留的 sandbox rootfs，否则旧 QEMU 镜像缓存还在，新配置根本不会加载。
