qemu64 CPU 模型为什么有 svm?兼容性模型的指令集设计

qemu64 是 qemu 的默认兼容性 CPU 模型,指令集很基础。但查看它的定义,居然包含 svm 这类虚拟化指令,这背后是 TCG 与 KVM 两种支持场景的差异。 现象 查看 qemu64 CPU 模型定义: cat /usr/share/libvirt/cpu_map/x86_qemu64.xml <cpus> <model name='qemu64'> <decode host='on' guest='on'/> <!-- These are supported only by TCG. KVM supports them only if the host does. So we leave them out: <feature name='abm'/> <feature name='lahf_lm'/> <feature name='popcnt'/> <feature name='sse4a'/> --> <feature name='apic'/> <feature name='clflush'/> <feature name='cmov'/> <feature name='cx16'/> <feature name='cx8'/> <feature name='de'/> <feature name='fpu'/> <feature name='fxsr'/> <feature name='lm'/> <feature name='mca'/> <feature name='mce'/> <feature name='mmx'/> <feature name='msr'/> <feature name='mtrr'/> <feature name='nx'/> <feature name='pae'/> <feature name='pat'/> <feature name='pge'/> <feature name='pni'/> <feature name='pse'/> <feature name='pse36'/> <feature name='sep'/> <feature name='sse'/> <feature name='sse2'/> <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> </model> </cpus> 分析 qemu64 是 qemu 为了兼容性提供的默认 CPU 模型,指令集非常基础。 但有意思的是,它居然包含了 svm(AMD 的虚拟化扩展指令)。 ...

July 12, 2026 · 1 min · 158 words · 文叨叨

虚拟机无响应?重启后快速进 console 看内核日志

虚拟机无响应,virsh console 卡住进不去。一个思路是重启后快速进入 console,看内核启动日志,往往能直接暴露根因。 现象 虚拟机无响应,virsh console 卡在下面这个地方: virsh console vm-example Connected to domain vm-example Escape character is ^] 排查思路 virsh console 卡在这地方,分两步: 多等一会看看,能否进去,可能是启动慢; 等几分钟还不行,那就是有问题了。 一个思路是重新启动,然后快速的进入 virsh console,可能能看到 kernel 启动日志,可能有线索: virsh destroy vm-example; virsh create vm-example.xml virsh console vm-example 比如这里就打印了日志: [ 2.313329][ T1] Run /init as init process Fatal glibc error: CPU does not support x86-64-v2 # 这里就是关键点,cpu 不支持 x86-64-v2 [ 2.315336][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 2.316635][ T1] CPU: 0 PID: 1 Comm: init Not tainted 6.6.0-28.0.0.34.oe2403.x86_64 #1 [ 2.317855][ T1] Hardware name: QingCloud E3, BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 2.319339][ T1] Call Trace: 根因 日志里 Fatal glibc error: CPU does not support x86-64-v2 就是关键线索——CPU 不支持 x86-64-v2 指令集,导致 init 进程直接 panic。 ...

June 14, 2026 · 1 min · 132 words · 文叨叨

为什么新系统跑不起来?默认 qemu 指令集不够用

新系统跑不起来,报 “CPU does not support x86-64-v2”,根因是现代 OS 默认按较新指令集编译,而默认的 qemu64 模型只提供最基础指令。给虚拟机配上合适的 CPU 指令集就能解决。 现象 一台 primusos2403sp1x64 的虚拟机,没有配置 CPU 指令集的情况下,运行僵死。配置指令集后,就能正常运行了。 排查 用 virsh reset vm-example && virsh console vm-example 可以看到 glibc 打印的错误: [ 1.536627][ T1] Run /init as init process Fatal glibc error: CPU does not support x86-64-v2 [ 1.538855][ T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 1.540681][ T1] CPU: 6 PID: 1 Comm: init Not tainted 6.6.0-103.0.0.106.oe2403sp1.x86_64 #1 [ 1.542633][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 1.545203][ T1] Call Trace: [ 1.545959][ T1] <TASK> [ 1.546568][ T1] dump_stack_lvl+0x32/0x50 [ 1.547593][ T1] panic+0x304/0x340 [ 1.548411][ T1] do_exit+0x3f4/0x410 [ 1.549284][ T1] do_group_exit+0x2d/0x80 [ 1.550272][ T1] __x64_sys_exit_group+0x14/0x20 [ 1.551151][ T1] do_syscall_64+0x55/0x100 [ 1.551963][ T1] entry_SYSCALL_64_after_hwframe+0x78/0xe2 [ 1.553370][ T1] RIP: 0033:0x7f40667d3db5 [ 1.557729][ T1] RSP: 002b:00007ffcb3db2f68 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 [ 1.559088][ T1] RAX: ffffffffffffffda RBX: 00007f40667cf490 RCX: 00007f40667d3db5 [ 1.560108][ T1] RDX: 0000000000000000 RSI: 00007ffcb3db2630 RDI: 000000000000007f [ 1.561078][ T1] RBP: 00007ffcb3db3140 R08: 0000000000000010 R09: 0000000000000000 [ 1.562048][ T1] R10: 0000000000000001 R11: 0000000000000202 R12: 00007f40667e2ab0 [ 1.563025][ T1] R13: 0000000000000000 R14: 0000000000000000 R15: 00007f40667b4000 [ 1.563990][ T1] </TASK> [ 1.564790][ T1] Kernel Offset: 0x38c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 1.566210][ T1] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]--- 根因 这是已知问题:现代操作系统都开启了指令集优化,纯 qemu 的模拟指令无法满足运行的基本要求,必须配上指令集才能运行。 ...

June 7, 2026 · 2 min · 280 words · 文叨叨

热迁移后虚拟机卡死:CPU 100% 的时间中断死循环

热迁移后虚拟机卡死、CPU 100%,往往是时间处理出了问题。用 crash 看 dump 能确认死循环卡在内核路径,再用 perf 在虚拟机内和宿主机上对比,就能定位到时间中断处理异常。 现象 把一台虚拟机从 Ubuntu 20 宿主机热迁移到 Ubuntu 22 宿主机后,虚拟机卡死了。 从宿主机看,virsh migrate 是成功的,虚拟机处于 running 状态,qemu 进程也正常。但被迁移的虚拟机 CPU 占用 100%,完全无响应。 排查 用 crash 分析 virsh dump 出来的内存转储,发现内核一直在刷下面的报错,看起来是死循环卡在了调度进程 swapper 上: [7686175795.936645] Call Trace: [7686175795.936647] <IRQ> [7686175795.936651] run_timer_softirq+0x2a/0x50 [7686175795.936655] __do_softirq+0xd1/0x2c1 [7686175795.936658] irq_exit+0xae/0xb0 [7686175795.936660] smp_apic_timer_interrupt+0x7b/0x140 [7686175795.936662] apic_timer_interrupt+0xf/0x20 [7686175795.936662] </IRQ> [7686175795.936664] RIP: 0010:native_safe_halt+0xe/0x10 [7686175823.935201] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0] 0 号进程就是 swapper 进程,也就是调度进程。 这种 CPU 100% 表现出来的卡死,必然是因为某种原因让 CPU 进入了死循环——CPU 被占住放不出来,无法执行其他进程,所以表现出来就是"卡死"。 ...

June 6, 2026 · 1 min · 114 words · 文叨叨

ARM 架构下 CPU 模型设置为什么失效?只有 passthrough

在 ARM(aarch64)架构下,libvirt/QEMU 的 CPU 模型与特性禁用设置不生效,虚拟机看到的 CPU 依然是透传的物理 CPU。所以 ARM 架构下,别探索什么指令集、热迁移了,全部用 passthrough。 现象 将虚拟机 CPU 设置为 custom 模式,指定 Kunpeng-920 指令集,并通过 <feature policy="disable"> 禁用 asimddp、asimdfhm 两个 CPU 特性。 对比宿主机与虚拟机内的 lscpu / /proc/cpuinfo 输出,发现设置未生效。 尽管 QEMU 进程命令行已携带 -cpu Kunpeng-920,asimddp=off,asimdfhm=off,虚拟机内部看到的 CPU 依然是透传的物理 CPU(特性、implementer、part 号与宿主机完全一致)。 排查 测试环境 项目 值 宿主机架构 aarch64 (ARM64) 宿主机 CPU HUAWEI Kunpeng 920 3210 (HiSilicon) 虚拟机架构 aarch64, machine virt-4.1 QEMU qemu-system-aarch64 (4.1.0.2) 虚拟化 KVM (accel=kvm) 虚拟机内存/CPU 1024 MiB / 1 vCPU 虚拟机 XML 的 CPU 部分 <cpu mode="custom" match="exact"> <model>Kunpeng-920</model> <feature policy="disable" name="asimddp"/> <feature policy="disable" name="asimdfhm"/> <topology sockets="1" cores="1" threads="1"></topology> <numa> <cell id="0" cpus="0" memory="1048576" unit="KiB" discard="yes"></cell> </numa> </cpu> QEMU 进程的 -cpu 参数 虚拟机启动后,QEMU 进程实际命令行中的 CPU 相关参数: ...

January 4, 2026 · 2 min · 414 words · 文叨叨