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 · 文叨叨

virsh attach/detach 的延时问题:重试不是灵药,可能是毒药

virsh detach 后 domblklist 有短暂延时,detach 成功后立即 detach 相同卷也能成功,两次重复 detach 后再 attach 会失败。根因是 libvirt 不是实时状态,有一定延时。 现象 已测试:连续 attach、detach、attach、detach… 反复是没有问题的。 有问题的: detach 后,virsh domblklist 是没有卸载的,要过一两秒,有短暂延时; detach 成功后,立即 detach 相同的卷,居然也可以成功。预期应该是会报错提示没有对应的卷; 两次重复的 detach 后,再 attach,attach 命令成功,但实际没有把卷挂载上。 根因 我们挺多奇怪的问题,可能都是类似的原因造成的。 libvirt 和 qemu: libvirt 不是实时状态,有一定延时; 然后一些重复操作,看上去是幂等的,但是它对后续操作有影响(其实也是 libvirt 的 bug)。 比如之前有过 domblk 和 qmp 查询卷不一样的情况,造成后续丢数据等。 设计思考 做重试之前,要充分测试。 是否达到了重试条件(状态、时间); 这个动作是否幂等; 对后续动作是否有影响。 重试不是灵药,可能是毒药。 小结 virsh detach 后 domblklist 有短暂延时,要过一两秒; detach 成功后立即 detach 相同卷也能成功,不符合预期; 两次重复 detach 后再 attach,attach 成功但实际没挂载上; 根因是 libvirt 不是实时状态,有一定延时; 做重试之前要充分测试,重试不是灵药,可能是毒药。

February 1, 2026 · 1 min · 73 words · 文叨叨

libvirt CPU feature 的 disable 和 forbid 有什么区别?

libvirt CPU feature 的 policy 有 force、require、optional、disable、forbid 五种。disable 是虚拟 CPU 不支持该特性,forbid 是宿主机支持该特性时创建会失败。 现象 在 libvirt XML 中配置 CPU feature: <cpu> <model>EPYC</model> <feature name="pclmuldq" policy="disable"/> <feature name="aes" policy="disable"/> <feature name="sha-ni" policy="disable"/> <feature name="monitor" policy="disable"/> <feature name="svm" policy="disable"/> <feature name="npt" policy="disable"/> 【物理机支撑 npt 的】 <topology cores="1" sockets="1" threads="1"/> </cpu> 物理 CPU 是有 npt 的,virsh create 的时候就报错,而且这是 disable 也报错。 足以说明,不是 CPU 问题,而是 libvirt 不支持问题: 2025-06-24 12:50:13,539 WARNING -140207347541760- cmd [virsh create /data/vmxml/vm-example.xml] on [local] failed: ret[1] out[] err[error: Failed to create domain from /data/vmxml/vm-example.xml error: unsupported configuration: unknown CPU feature: npt]. exec_time is [0.089]s 排查 在 commandline 中禁用 npt 是可以创建虚拟机的 <qemu:commandline> <qemu:arg value="-cpu"/> <qemu:arg value="EPYC,vendor=AuthenticAMD,model_id=Example CPU 7380 32-core Processor,-x2apic,-hypervisor,-topoext,-npt,-nrip-save,-monitor,-svm"/> </qemu:commandline> 说明什么? ...

January 31, 2026 · 2 min · 267 words · 文叨叨

ARM 虚拟机缺 acpi 为什么登录没反应?

ARM 虚拟机配置中 <features> 区块缺少 <acpi/>,表面现象是 virsh console 登录没反应。根因是 ACPI 缺失导致系统底层硬件/服务初始化异常,间接引发登录流程失败。 现象 ARM 虚拟机配置中 <features> 区块里缺少 <acpi/>,虚拟机异常。 表面现象是 virsh console 的时候登录没有反应。 这种时候其实都是虚拟机启动阶段就有问题了。 排查 各 feature 的作用 <apic/> - 高级可编程中断控制器(Advanced Programmable Interrupt Controller) 这是 x86 架构的中断控制器标准,替代老式的 8259 PIC; 负责管理 CPU 的中断请求(比如硬件设备的信号、定时器中断等); 支持多核心 CPU 的中断分发、中断优先级控制、中断重映射等; 对 ARM 环境的意义:ARM 架构不使用 APIC,这个配置属于冗余配置(无实际作用),是兼容 x86 配置模板留下的,删除也不会影响 ARM 虚拟机运行。 <pae/> - 物理地址扩展(Physical Address Extension) 这是 32 位 x86 架构的内存扩展技术,让 32 位 x86 系统突破 4GB 物理内存的访问限制(最大支持 64GB); 对 ARM 环境的意义:你的环境是 64 位 ARM(aarch64),天然支持大于 4GB 的内存寻址,<pae/> 完全无作用,属于冗余配置。 <acpi/> - 高级配置与电源接口(Advanced Configuration and Power Interface) ...

January 25, 2026 · 1 min · 191 words · 文叨叨

qemu 为什么只支持一个 IDE controller?

qemu 只支持一个 IDE controller,一个 IDE controller 只支持 4 个设备(hda 到 hdd)。定义两个 IDE controller 或使用 hde 都会报错。 现象 在 libvirt XML 中定义两个 IDE controller: <controller type='ide' index='0'/> <controller type='ide' index='1'/> 直接会报如下错误: error: Failed to create domain from vm-example.xml error: unsupported configuration: Only a single IDE controller is supported for this machine type 排查 默认有一个 IDE controller 默认有一个 IDE controller。 所以不定义 <controller type='ide' index='0'/>,也是有一个 IDE controller 的。 直接定义 IDE disk 的情况 <disk type="network" device="cdrom"> <driver name="qemu" type="raw"></driver> <source protocol="http" name="/yy/img-example.iso"> <host name="qa1b01" port="8021"></host> </source> <target dev="hdd" bus="ide"></target> 【注意 hdd】 <readonly></readonly> <shareable></shareable> </disk> 直接定义了 IDE 的 disk,没有定义 IDE 的 controller。 ...

January 24, 2026 · 1 min · 174 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 · 文叨叨