企业官网建设流程全解析

先交代一个现实：天玑9400是ARM架构的移动端旗舰SoC，KVM是Linux内核虚拟化模块，Windows 10 on ARM又是另一套体系，要把三者串起来，中间隔着的坑比表面上多得多。这篇文章会把完整链路拆开讲清楚：从硬件可行性确认，到QEMU/KVM虚拟机创建，到Windows 10 on ARM安装，再到CPU-Z检测和结果解读，最后补充常见问题和工程建议。适合对ARM虚拟化感兴趣的开发者，也适合想在旗舰ARM设备上做Windows实验的折腾型玩家。

1. 背景与核心概念

1.1 天玑9400的硬件底子

天玑9400是联发科面向旗舰手机市场的SoC，根据公开资料，它采用台积电3nm工艺，CPU部分采用经典的1+3+4架构：1颗Cortex-X925超大核、3颗Cortex-X4大核、4颗Cortex-A720能效核。GPU是Immortalis-G925。这里的核心信息是：天玑9400的CPU IP在硬件层面支持ARM虚拟化扩展，也就是具备运行KVM所需的EL2异常级别。

但需要注意，芯片支持虚拟化，不等于你手上的手机或开发板就一定能用KVM。一台设备能否真正跑KVM，还要看厂商内核是否开启了KVM模块、系统是否暴露了/dev/kvm节点、用户是否有足够权限。这也是后文要先检查环境的原因。

1.2 KVM、QEMU与qemu-kvm的关系

很多新手会把KVM和QEMU混在一起说，实际上它们是两层东西：

• QEMU是一个通用模拟器，可以纯软件方式模拟CPU和外设，这种模式叫TCG，优点是兼容性好，缺点是慢。
• KVM是Linux内核提供的硬件虚拟化模块，它让虚拟机可以直接使用宿主CPU的硬件虚拟化能力，性能接近原生。
• qemu-kvm是二者的组合：用QEMU管理设备、提供虚拟机生命周期，用KVM做CPU和内存加速。

和VMware Workstation、VirtualBox这类x86桌面虚拟化工具相比，KVM/QEMU更强调命令行和Linux生态，常见组合是libvirt + virt-manager + QEMU/KVM。Proxmox VE这类虚拟化平台底层也是KVM/QEMU。本文的场景是天玑9400设备上的ARM64 KVM，所以直接围绕QEMU/KVM展开。

1.3 为什么要跑Windows 10 on ARM并用CPU-Z检测

Windows 10 on ARM是微软为ARM64设备准备的Windows版本，它有三层生态：ARM64原生应用、x86模拟应用、部分x64模拟应用。CPU-Z是常见的CPU信息检测工具，能够展示处理器型号、核心数、频率、缓存、指令集等，也可以跑简单的单核和多核基准测试。

在天玑9400设备上用qemu-kvm启动Windows 10 on ARM，再运行CPU-Z，本质上是为了验证两件事：

• 这条KVM虚拟化链路是否完整可用，包括UEFI引导、磁盘驱动、显示输出、网络配置。
• Windows on ARM在虚拟机中能够识别到什么样的CPU信息，虚拟化和模拟层会对CPU-Z造成多大影响。

这里要提前说清楚：CPU-Z检测到的是“虚拟机呈现给Windows的CPU”，不一定是天玑9400完整的物理形态。后文会专门解读。

1.4 适用场景与不适合的场景

这类实验适合以下场景：

• 想学习ARM64虚拟化原理，特别是KVM在非x86平台上的使用。
• 想测试Windows on ARM在自定义虚拟硬件上的驱动兼容性。
• 想用CPU-Z这类工具了解Windows on ARM对CPU信息的识别方式。
• 对移动端SoC跑Windows有好奇心，想验证系统能不能启动、基本功能是否正常。

不适合的场景也很多：

• 指望虚拟机里流畅跑Windows桌面应用。
• 想通过CPU-Z跑分来衡量天玑9400真实性能。
• 想把Windows on ARM当作日常系统长期使用。

原因很简单：驱动、散热、功耗、虚拟化开销都会严重影响体验，这类实验更适合作为“验证技术链路”的极客项目。

2. 环境准备与硬件可行性分析

2.1 先确认KVM是否真的可用

这是整个实验的生死线。如果宿主没有KVM，QEMU只能退回TCG纯软件模拟，Windows 10 on ARM的安装过程会慢到难以接受，通常不推荐继续。

检查KVM是否可用的最直接命令是：

ls -l /dev/kvm

如果输出类似crw-rw---- 1 root kvm 10, 232 ... /dev/kvm，说明内核已经把KVM节点暴露出来了。如果提示No such file or directory，说明内核没有开启KVM或设备没有暴露该节点。

还可以再查看内核日志：

dmesg | grep -i kvm

在部分Linux发行版上，也可以查看CPU信息中的虚拟化特性：

lscpu | grep -i virtualization

需要说明的是，Android设备默认通常没有/dev/kvm，即使天玑9400芯片支持虚拟化扩展，厂商内核也不一定开启了KVM。如果使用Android + Termux方案，大概率只能跑TCG，性能损耗很大。最理想的环境是设备能跑完整的ARM64 Linux发行版。

2.2 宿主机系统与软件包准备

本文以ARM64 Linux宿主环境为例，Debian/Ubuntu系发行版可以这样安装软件包：

sudo apt update sudo apt install qemu-system-arm qemu-utils qemu-efi-aarch64 \ libvirt-daemon-system virtinst virt-manager

这里简单说明每个包的作用：

• qemu-system-arm：包含QEMU对ARM和AArch64架构的支持，提供qemu-system-aarch64命令。
• qemu-utils：提供qemu-img等磁盘管理工具。
• qemu-efi-aarch64：提供ARM64 UEFI固件文件，这是Windows on ARM启动所必需的。
• libvirt-daemon-system和virtinst：提供libvirt虚拟化管理层和virt-install命令行安装工具。
• virt-manager：图形化管理工具，适合不习惯纯命令行的用户。

不同发行版的包名会有差异，比如CentOS/RHEL系可能叫qemu-kvm、edk2-aarch64等。版本需要根据你的项目实际情况调整，重点是理解需要哪些组件，而不是死记包名。

2.3 镜像和工具准备

准备阶段需要三个关键文件：

• Windows 10 on ARM安装镜像。优先从微软官方或OEM授权渠道获取。普通用户可能很难直接拿到Windows 10 on ARM的官方ISO，这种情况下可以优先考虑微软当前支持的Windows 11 on ARM版本做替代实验。
• CPU-Z安装包。建议去官网下载，优先选择支持Windows on ARM的版本。如果只有x86版本，Windows on ARM内置的模拟层也能运行，但代表的是模拟兼容性的路径。
• virtio驱动ISO。用于安装virtio磁盘、网卡、显卡等驱动的镜像，需要确认支持Windows on ARM的版本。

特别强调合规问题：不要从不信任的第三方站点下载系统镜像和工具，也不要绕过设备或系统授权机制。实验归实验，授权和合规边界要守住。

2.4 宿主资源评估

Windows 10 on ARM虚拟机最低建议4GB内存，实际实验建议8GB。磁盘建议至少分配64GB，qcow2格式按需占用空间，不会马上占满64GB。如果天玑9400设备是手机形态，还要考虑存储余量、散热条件和功耗限制，长时间高负载安装Windows会让机身明显发热。

准备工作做完后，最好先确认一个结论：如果/dev/kvm可用，整个实验才有意义；如果不可用，后续步骤可以直接跳过，或者仅作为QEMU模拟学习参考。

3. 创建ARM64虚拟机前的准备工作

3.1 理解ARM64虚拟机为什么需要UEFI

Windows on ARM不支持传统BIOS启动方式，必须通过UEFI引导。但QEMU的virt机型默认不自带UEFI固件，需要手动指定。

安装qemu-efi-aarch64后，固件文件一般会出现在类似路径：

/usr/share/qemu-efi-aarch64/QEMU_EFI.fd /usr/share/qemu-efi-aarch64/QEMU_VARS.fd

有些发行版放在/usr/share/AAVMF/目录下，文件名可能是AAVMF_CODE.fd和AAVMF_VARS.fd。实际操作时用dpkg -L qemu-efi-aarch64或find /usr/share -name "*EFI*.fd"定位即可。

3.2 创建虚拟磁盘

使用qemu-img创建64GB的qcow2磁盘：

mkdir -p ~/vm qemu-img create -f qcow2 ~/vm/windows10-arm.qcow2 64G

查看磁盘信息：

qemu-img info ~/vm/windows10-arm.qcow2

qcow2格式的优势是按需增长，64G只是磁盘容量的“上限”，刚开始文件可能只有几百KB。后续还可以使用qemu-img snapshot做快照，对实验排错很有帮助。

3.3 手动启动QEMU虚拟机

手动启动QEMU命令适合排查问题，也更容易理解每个参数的含义。下面给出一个完整示例：

qemu-system-aarch64 \ -machine virt,virtualization=on,gic-version=3 \ -cpu host -enable-kvm \ -smp 8 -m 8192 \ -drive if=pflash,format=raw,readonly=on,file=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd \ -drive if=pflash,format=raw,file=/usr/share/qemu-efi-aarch64/QEMU_VARS.fd \ -drive file=~/vm/windows10-arm.qcow2,if=none,id=disk0,format=qcow2 \ -device nvme,drive=disk0,serial=wd10arm01 \ -drive file=~/iso/Win10_ARM64.iso,media=cdrom,readonly=on \ -device ramfb -vga none \ -netdev user,id=net0 \ -device virtio-net-pci,netdev=net0 \ -boot d

逐段解释：

• -machine virt,virtualization=on,gic-version=3：使用QEMU的virt虚拟化机型，显式开启虚拟化扩展，GIC使用3版本。
• -cpu host -enable-kvm：把宿主CPU能力直接透传给虚拟机，并启用KVM加速。两者必须配合使用。
• -smp 8 -m 8192：分配8个vCPU和8GB内存。
• -drive if=pflash...：加载UEFI固件。第一块pflash只读，第二块可写，用于保存UEFI变量。
• -drive file=...qcow2,if=none,id=disk0和-device nvme：用NVMe控制器挂载系统盘。Windows 10自带标准NVMe驱动，这种方式可以避免安装时找不到磁盘。
• -drive file=...iso,media=cdrom,readonly=on：挂载Windows安装镜像。
• -device ramfb -vga none：使用RAM framebuffer做显示输出，Windows安装阶段通常能识别为基础显示适配器。
• -netdev user,id=net0和-device virtio-net-pci：配置用户态网络。需要注意，virtio-net驱动需要进入Windows后安装，安装系统阶段可能没有网络。
• -boot d：虚拟机优先从光驱启动。

如果宿主没有KVM，可以尝试去掉-enable-kvm -cpu host，改用-cpu max或-cpu cortex-a76，QEMU会退回TCG模式。系统也许能启动，但速度非常慢，Windows安装基本不现实。

3.4 使用libvirt和virt-install管理虚拟机

手动命令行适合临时测试，但如果想长期管理、快照、开机自启，还是建议用libvirt。创建虚拟机的命令示例如下：

virt-install \ --name win10arm \ --memory 8192 \ --vcpus 8 \ --cpu host-passthrough \ --arch aarch64 \ --machine virt \ --boot uefi \ --disk path=~/vm/windows10-arm.qcow2,format=qcow2 \ --cdrom ~/iso/Win10_ARM64.iso \ --os-variant win10 \ --network default \ --graphics spice

如果提示不认识win10这个os-variant，可以先查看系统支持的名称列表：

osinfo-query os | grep -i windows

使用libvirt时要注意UEFI固件是否能自动找到。部分发行版需要额外安装edk2-aarch64或AAVMF包，否则可能提示找不到ARM UEFI。此时可以检查/usr/share/AAVMF或/usr/share/qemu-efi-aarch64目录是否存在。

4. 安装Windows 10 on ARM的完整实战

4.1 启动安装引导

启动虚拟机后，如果一切正常，会看到UEFI界面或Windows安装界面。如果卡在UEFI Shell，说明启动顺序不对。在UEFI Shell中输入exit，然后进入Boot Manager，手动选择虚拟光驱启动。

Windows安装程序启动后，按常规流程选择语言、键盘布局、系统版本，然后进入“自定义安装”。整个过程和x86版Windows安装类似，只是底层引导方式变成了ARM64 UEFI。

这里有一个常见坑：Windows安装过程会多次重启。如果光驱中还保留着安装ISO，重启后可能会再次进入“Press any key to boot from CD/DVD”提示。此时不按任意键，让系统从硬盘引导即可；或者在UEFI启动菜单中选择硬盘启动。

4.2 磁盘识别与安装驱动

如果按照前文的启动命令使用了NVMe设备，Windows安装程序通常能直接识别磁盘，不需要额外加载驱动程序。选择未分配空间，新建分区，继续安装。

如果使用的磁盘设备是virtio-blk，安装时Windows可能找不到硬盘。解决办法是在安装界面点击“加载驱动程序”，然后加载包含ARM64 virtio驱动的介质。这也是很多人卡住的地方，建议优先使用NVMe方案避开这个坑。

4.3 进入系统后的基础设置

第一次进入Windows 10 on ARM桌面后，需要完成区域、账户、隐私等设置。如果virtio-net网卡驱动还没安装，就不要强行联网，先使用本地账户完成系统初始化。

打开设备管理器看一眼，大概率会看到一些带黄色感叹号的未知设备，比如PCI设备、网卡、显卡、气球驱动等。这些需要后续安装virtio驱动来识别。

4.4 安装virtio驱动并补齐设备

把包含virtio-win ARM64驱动的ISO挂载到虚拟机中，在设备管理器中逐个更新未知设备的驱动，或者直接运行驱动安装脚本。驱动安装后，以下几点会明显改善：

• 网卡从“未知设备”变成可用状态，虚拟机才能正常联网。
• 磁盘IO性能提升，virtio-blk或virtio-scsi比模拟设备更高效。
• balloon驱动正常工作，宿主可以动态回收虚拟机空闲内存。
• pvpanic驱动可以让虚拟机发生panic时向宿主报告异常。

如果找不到现成的ARM64 virtio-win ISO，可以先保持NVMe磁盘+ramfb显示的方式继续实验，网络等功能后续再补。不建议为了装驱动而绕过Windows驱动签名机制，除非你清楚风险并且只在测试环境操作。

4.5 运行CPU-Z并通过检测结果做初步判断

在虚拟机中打开CPU-Z，主界面会显示处理器名称、封装、核心数、线程数、频率、缓存、指令集等信息。由于QEMU使用-cpu host透传宿主CPU能力，CPU-Z大概率会识别出一个通用的ARM64处理器名称，而不是“MediaTek Dimensity 9400”这样的品牌型号。

这个现象很正常。虚拟化层让Windows看到了宿主的CPU特性，但Windows on ARM对CPU品牌的识别依赖ACPI或其他固件信息，QEMU的virt机型本身并不模拟手机SoC的完整品牌信息。

如果CPU-Z能进入Benchmark界面，可以跑一下单核和多核分数。但分数只能说明“这台Windows虚拟机中的CPU性能”，不能直接当作天玑9400的跑分报告。

5. 性能与结果解读建议

5.1 虚拟化开销到底去了哪里

KVM接管了CPU和内存的大部分虚拟化工作，所以CPU密集型的压力测试效率较高。真正拖后腿的往往是设备模拟层：磁盘、网卡、显示、USB等设备如果没有virtio驱动，每次IO操作都会经过更长的模拟路径，体感就变得很卡。

把Windows on ARM安装到NVMe设备、给网卡装好virtio-net驱动、给显卡装好virtio-gpu驱动之后，整体体验会有明显提升。这也是为什么“驱动是否完整”是Windows on ARM虚拟机性能的关键变量。

5.2 CPU-Z识别的是虚拟机CPU还是天玑9400

严格来说，CPU-Z看到的是“虚拟CPU”而不是“物理芯片的全部信息”。使用-cpu host透传时，虚拟CPU继承了宿主的ARM指令集特性和部分核心拓扑，但Windows侧的SMBIOS/ACPI信息由QEMU生成，可能只包含QEMU Standard PC之类的通用字符串。

所以检测结果可以分为两层理解：

• 指令集和特性层面，值得参考，因为透传模式下虚拟CPU能使用宿主的大部分硬件特性。
• 品牌型号和跑分层面，只能算虚拟机视角的参考数据，不能等同于天玑9400的真实性能。

5.3 影响最终测试结果的因素

即使KVM链路完全正常，最终CPU-Z的分数还会受以下因素影响：

• vCPU拓扑设置-smp 8与实际物理核心的对应关系。
• Windows电源计划是高性能还是平衡。
• 宿主的散热和功耗限制，尤其是手机或轻薄ARM设备，高负载下很容易触发降频。
• 网络、磁盘、后台进程对CPU的抢占。
• virtio驱动是否安装完整。

建议多次运行CPU-Z的Bench，观察分数波动，不要只凭一次结果下结论。

6. 常见问题与排查思路

下表总结了本实验中最容易出现的问题，以及对应的排查方向：

排查建议按这个顺序来：

1. 先确认宿主KVM可用，没有KVM后面所有性能问题都无解。
2. 确认UEFI固件路径正确，Windows on ARM必须有UEFI。
3. 确认磁盘设备类型，优先NVMe，其次安装virtio驱动。
4. 确认显示输出模式，优先ramfb，不要一上来就用virtio-gpu。
5. 进入系统后再补装virtio驱动，逐步解决网卡、显卡、气球等设备。

7. 最佳实践与工程建议

7.1 先用轻量Linux guest验证KVM链路

直接拿Windows on ARM做实验，问题层级太多，如果失败很难判断是UEFI问题、磁盘问题还是Windows本身的问题。更稳妥的路径是先在同一个QEMU/KVM环境中跑一个轻量ARM64 Linux虚拟机，比如官方云镜像。如果Linux guest能正常启动、看到/dev/kvm加速生效，再切换到Windows on ARM实验，排错面会小很多。

7.2 用libvirt统一管理并善用快照

手动QEMU命令适合验证参数，但正式实验建议使用libvirt管理。快照是排错利器，在安装完Windows、装好virtio驱动、准备运行CPU-Z之前各打一个快照，出现问题时可以快速回滚。

创建快照示例：

virsh snapshot-create-as win10arm snapshot-win-installed --description "Windows installed and virtio drivers ready"

查看快照列表：

virsh snapshot-list win10arm

恢复到指定快照：

virsh snapshot-revert win10arm snapshot-win-installed

7.3 尽量使用virtio驱动体系

KVM虚拟化环境下，virtio是性能最佳的设备模型。磁盘、网卡、balloon、显卡都应该优先选择virtio对应驱动。如果Windows on ARM的virtio驱动难找，至少要保证磁盘和网卡的驱动可用，否则虚拟机体验会很差。

需要注意，不要为了装驱动而关闭驱动签名校验。实验环境如果确实需要测试，也应该先备份快照，并在可控范围内操作。

7.4 镜像和工具来源要合规

Windows on ARM镜像、CPU-Z、virtio-win等资源都存在来源问题。镜像和工具尽量从官方渠道获取，避免使用来路不明的精简版、修改版。实验过程如果涉及授权校验，不要试图绕过授权。合法合规是技术实验的基本前提。

7.5 关注移动SoC的散热与功耗

天玑9400是旗舰移动SoC，性能释放高度依赖散热条件。长时间运行Windows安装过程会让SoC高负载工作，如果设备散热一般，很可能触发温控降频，表现为虚拟机越来越卡、CPU-Z分数低于预期。这种情况下可以尝试降低vCPU数量、减少内存分配，或者给设备加主动散热。

7.6 明确测试目标，不要被跑分误导

做这个实验的核心目标是验证“天玑9400设备上能否用qemu-kvm跑Windows on ARM，并让CPU-Z正常工作”，而不是“证明天玑9400在Windows下有多强”。明确目标之后，跑分只是辅助参考，KVM链路是否可用、驱动是否完整、系统能否稳定运行才是真正重要的结论。

8. 总结与后续学习路线

这条实验链路虽然看起来只是“装个虚拟机、跑个CPU-Z”，实际牵扯到的知识点非常密集：ARM架构的EL2虚拟化扩展、KVM在非x86平台上的支持状态、ARM64 UEFI引导、Windows on ARM的驱动模型、QEMU设备模拟与virtio加速、CPU-Z对虚拟CPU的识别逻辑。

如果实验顺利完成，值得记录下几个关键信息：宿主设备、Linux发行版与内核版本、QEMU版本、UEFI固件路径、Windows on ARM版本、virtio驱动版本、CPU-Z检测到的核心数和指令集。这些信息对日后复现和调优都很有价值。

下一步可以继续深入的方向包括：

• 尝试Windows 11 on ARM，对比系统兼容性和驱动差异。
• 研究libvirt XML配置，把虚拟机的CPU拓扑、内存、设备参数固化下来。
• 学习ARM虚拟化的底层原理，包括异常级别、GIC中断控制器、Stage-2页表。
• 尝试用Proxmox VE这类基于KVM/QEMU的管理平台统一管理多台ARM虚拟机。
• 深入理解Windows on ARM的x86模拟层，看看在虚拟机中运行x86应用时CPU-Z的表现差异。

回到最开始的判断：如果/dev/kvm不存在，这个实验基本可以放弃；如果KVM链路正常，哪怕CPU-Z识别出的不是“MediaTek Dimensity 9400”这个品牌字符串，也说明你已经成功地把Windows on ARM放进了天玑9400设备的虚拟化环境中。接下来要做的，就是不断优化驱动和配置，让虚拟机从“能启动”走向“能稳定运行”。