企业官网建设流程全解析

1. 为什么IoT设备需要Hypervisor：混合关键性需求带来的架构转型

很多人第一次在电脑上跟“hypervisor”打交道，是因为安装了Android模拟器，或者在某台Windows机器上装了VMware。但如果你在工业现场、车载设备或者边缘网关的选型会上听到“ACRN”，那说的是完全不同的另一类东西——一个从设计第一天就盯住IoT场景的开源Type-1 Hypervisor。

前阵子一个做工业边缘网关的同事找我，说他被一个需求卡住了：现场设备要同时跑三套东西——采集PLC数据的实时控制程序、做视觉检测的AI推理模型、还有个第三方SDK要跑在容器里。控制程序要求响应延迟在毫秒级，AI推理要占掉大半CPU，第三方SDK又不知道里面有什么代码，不敢让它碰底层硬件。他先试了容器，用Docker做了资源限制，结果控制程序的调度延迟还是时不时飙到几十毫秒，而且某个内核模块一崩溃，三个业务全跟着重启。后来他又想上KVM，可一台工控机的资源本来就紧张，再跑个完整Linux宿主，光内存就得吃掉好几个G。

这种场景十多年前在服务器领域就有答案，叫虚拟化。但服务器虚拟化设计的出发点是把一台大机器切成多台小机器，追求的是弹性和资源利用率，而IoT设备上需要的是另一套逻辑：在性能有限的嵌入式平台上，把不同安全等级、不同实时要求的负载放进同一个物理系统，同时保证它们互不干扰。这就是ACRN 2.0这个开源项目要解决的问题。

1.1 一次让我重新思考“隔离”的现场项目

我同事那个项目，后来我们坐下来仔细过了一遍。控制系统跑在裸机上的时候，最坏中断延迟大概在几十微秒左右；上了Linux之后，因为有内核调度、中断关闭、Cache抖动这些因素，最坏延迟能到几百微秒甚至几毫秒；再叠加容器共享内核导致不可控，系统根本没法给出硬实时承诺。而AI推理和第三方SDK这些非实时负载，反而需要尽可能多的时间片和内存带宽。

这种需求形态，行业里称为混合关键性。ACRN的典型用法就是：用Type-1 Hypervisor管住全部硬件资源，上面跑一个特权级的Service VM（通常是一个定制Linux，ACRN里叫Service OS），负责管理外设、网络、存储，然后再跑若干个User VM，每个User VM里放一个独立的Guest OS，实时任务和普通任务彻底分开。控制系统放在一个专属VM里，给它绑定固定CPU核心和优先级；AI推理放另一个VM里，占大内存和大部分CPU；第三方SDK单独一个VM，即便它把Guest OS整个干崩溃，其他两个VM一点不受影响。

1.2 混合关键性：IoT虚拟化的真正驱动力

混合关键性这个概念，最早来自航空航天和汽车电子：一个域控制器里，刹车控制和安全气囊是ASIL-D等级，但娱乐系统只需要QM等级，它们跑在一块芯片上，必须从硬件层面保证互不干扰。这个逻辑放到工业IoT、边缘计算、机器人上完全成立——控制类任务出了事会砸设备，但日志分析任务出了事最多丢点数据，两者不能混在一个系统里，也不能用性能黑洞般的纯软件隔离方案。

ACRN选择用Type-1架构来做这件事，逻辑很直接：Type-2 Hypervisor（比如KVM）必须先有一个宿主机操作系统跑起来，hypervisor只是宿主内核的模块。这意味着所有虚拟机出问题前，宿主机本身就成了一个巨大的故障面，而且资源调度绕不开宿主Linux的全局策略。Type-1则不同，Hypervisor直接跑在裸机上，拥有硬件最高特权级，它本身只做最关键的事情——CPU调度、内存虚拟化、中断管理、VM切换，其他一切交给上层VM。ACRN号称整个Hypervisor代码量非常小，这让它的可信计算基（TCB）小得多，攻击面、故障面都窄，安全审计也容易得多。

另一个点，是启动速度和资源占用。IoT设备不像数据中心有几十台物理机做冗余，它要的就是开机快、占得少、确定性强。ACRN在支持良好的平台上，从UEFI电源键到Service VM起来、USB枚举完成，能做到很短。相比之下，KVM那套要先起Linux、再起系统服务、再做虚拟化配置，在嵌入式场景下明显笨重。

1.3 为什么不是容器：隔离级别和资源可控性的差异

我经常被问到一个问题：现在都用容器了，为什么还搞虚拟化？这里要分清楚两类隔离的层次差异。容器共享宿主内核，隔离依赖的是命名空间和CGroup等内核机制，本质上是软件实现的边界；而虚拟机是CPU硬件层面的隔离——每个VM有自己独立的页表、独立的寄存器上下文、独立的中断路由，Hypervisor用硬件虚拟化扩展（Intel VT-x/VT-d）来强制隔离。对安全要求高的IoT场景，硬件隔离和软件隔离不在一个可信等级上。

还有一个更实际的差异：确定性。容器里的任务最终还是要跟宿主机上其他容器争Linux内核里的各种锁、调度器时间片、内存回收线程。你很难在一个容器里对中断延迟做出硬保证。而ACRN这类Type-1 Hypervisor可以把某个pCPU核心完全留给实时VM，通过vCPU亲和性和调度策略，让实时VM在专属核心上运行，几乎不跟其他VM共享任何执行资源。这种确定性，是容器方案给不了的。

当然，容器在IoT场景也有它的位置——比如Service VM内部再跑Kubernetes或Docker，把不需要硬件强隔离的微服务放进去，这跟我后面要说的ACRN架构完全不冲突。所以准确的说法是：在ACRN的体系里，Hypervisor负责硬隔离和资源划分，容器负责软隔离和应用分发，两者是分层配合的关系，不是非此即彼。

2. ACRN 2.0的架构设计拆解：Type-1、设备直通与实时性从哪来

ACRN如果只看官方文档，会看到一堆缩写和架构图，容易劝退。我用自己的理解把它的核心机制拆成三块：整体架构怎么分工、设备怎么高效地给虚拟机用、CPU和内存的隔离到底怎么做到硬实时。把这三点想清楚，后面部署调优就有谱了。

2.1 总体架构：Hypervisor、Service VM与User VM三方分工

ACRN把运行在最高特权级（root mode）的Hypervisor放最底层，它是整个系统的心脏。这一层只做虚拟化的基本工作：截获特权指令、维护VM控制块、处理VM exit/VM entry、管理中断和定时器、实现内存虚拟化（EPT）。ACRN还专门为嵌入式场景做了一些裁剪，比如支持无中断（posted interrupt）的直通设备中断注入，减少VM切换开销。

Service VM是系统中唯一拥有全部物理资源视图的特权级VM，通常跑一个定制Linux。它扮演“管家”角色：所有物理设备驱动优先挂在Service VM里，User VM要用某种网络功能时，通过Hypervisor做VirtIO后端，把虚拟设备转发给User VM。这种做法的核心好处是驱动复杂度集中在特权VM，User VM的Trusted Computing Base显著减小。换句话说，只要Service VM不被打穿，整个系统的安全性就有保障。

User VM则是承载具体业务的隔离环境，可以跑普通Linux、实时Linux（带PREEMPT_RT补丁）、Zephyr这类轻量RTOS，也有社区跑过Android。每个User VM只看到Hypervisor分配给它的虚拟CPU、虚拟内存和设备，天然跟其他VM隔开。ACRN 2.0在User VM管理上的一个重要进步，是支持更灵活的虚拟设备配置和更细粒度的资源分配——比如可以给User VM分配非连续的物理内存（通过内存热插拔和预留），这在旧版本里限制很多。

2.2 设备直通与中介传递：性能怎么保住的

虚拟化的性能损失主要来自I/O路径。如果每个网络包都要经过Hypervisor/SOFTIRQ多次拷贝，延迟和CPU占用都会飙。ACRN对设备分了两类处理：

第一类是实时性要求极高的设备，用PCI Passthrough（也叫设备直通）方式。直通设备对User VM来说就像独占硬件，Guest驱动直接操作设备的MMIO寄存器，中断通过VT-d的中断重映射直接注入到目标vCPU，Hypervisor只在VM切换时做少量工作。典型例子是网卡的SR-IOV虚拟功能、GPU、FPGA加速卡、工业总线控制卡。直通的前提是BIOS开了VT-d，并且IOMMU映射配置正确。

第二类是常规设备，走VirtIO中介传递。Service VM里的QEMU兼容层（ACRN Device Model，也就是acrn-dm）为User VM提供virtio-blk、virtio-net等虚拟设备，Guest用VirtIO驱动跟后端通信。这种方式牺牲了一部分性能，但换来了极大的灵活性——比如一个物理网卡可以被多个VM虚拟出各自的虚拟网卡。我实测下来，ACRN的VirtIO路径相比裸机性能大概有10%到20%的损耗，如果开多队列（virtio-net mulitqueue）并把VirtIO轮询线程绑定到跟Guest vCPU不同的核心上，损耗还可以进一步压低。

设备这块，ACRN 2.0还加强了PCIe AER错误处理的透传——以前直通设备一报错，User VM可能直接挂掉，现在Hypervisor能把错误事件转发给Service VM做处理，不会牵连整个系统。这个能力在工业现场很关键，因为PCIe链路抖动其实是常见故障源。

2.3 vCPU调度与内存隔离：实时性来自细节

ACRN的vCPU调度器不是简单的加权公平队列，它提供多种调度策略。默认策略下每个vCPU在pCPU上轮转，适合普通负载；但对实时VM，可以把它固定绑定到某个或某几个pCPU上，也就是独占核心，配合Guest内部的PREEMPT_RT，就能保证中断和任务调度的确定性。这个设置需要在板级配置里指定vcpu affinity，编译时写死；2.0版本还支持运行时通过acrnctl做动态调整，但我个人建议关键实时VM还是编译期绑死比较稳。

内存隔离方面，ACRN依赖Intel EPT（Extended Page Tables）做每VM二级地址转换。EPT本身就是硬件页表，VM的Guest物理地址要访问宿主机物理内存，必须经过EPT walk，所以Guest无法访问未分配的内存区域。Hypervisor自己占用的内存，则通过设置EPT条目里的内存类型和权限位来保护，User VM即使拿到漏洞利用代码，也够不着Hypervisor的私有数据。对于更高级别的安全需求，ACRN还支持Intel MEE（Memory Encryption Engine）做内存加密，防止物理攻击者通过探测DRAM总线窃取数据，车载和军工场景可能会用到。

实时性还藏在一些细节里：ACRN支持本地APIC虚拟化（vLAPIC），Guest直接操作虚拟中断控制器，不需要频繁陷入Hypervisor；支持Posted Interrupt，直通设备的中断可以不经过VM exit直接注入vCPU，大大降低中断延迟。配合2.0版对中断源路由的优化，实时VM的中断延迟在典型工控平台上能到几十微秒量级。这背后每一步都是对“确定性”的极致追求——IoT实时系统怕的不是慢，是怕不可预测的抖动。

3. 从源码到启动：ACRN 2.0在真实硬件上的部署全过程

ACRN的部署流程跟你在普通服务器上装KVM不太一样。它需要针对具体开发板做配置，然后编译Hypervisor、Service VM内核、Device Model三个部分，最后通过GRUB或EFI引导。很多人第一次搞被这堆步骤绕晕了，我把完整过程列出来，按顺序走一遍基本不会跑偏。

3.1 环境准备：检查CPU、BIOS和内存布局

第一步不是下载代码，而是检查你的硬件是否满足要求。ACRN目前主要支持Intel x86平台，CPU必须支持VT-x和VT-d。VT-x是CPU虚拟化基础指令，VT-d是设备直通和IOMMU的关键——如果BIOS里没有开启VT-d，后面直通设备都会失败，所以先开机进BIOS确认这两个选项（名字可能是“Intel Virtualization Technology”和“VT-d”）都打开。

第二步确认内存布局。Hypervisor预留内存需要一定的物理内存顶部连续区域，具体大小看配置；如果板子内存小于某个阈值（比如低于4GB），而且BIOS没有预留好RAM，Hypervisor可能无法启动。ACRN提供了一个Board Inspector工具，可以在直接运行Linux的板子上抓取硬件资源信息，生成board XML文件。这个XML包含了内存范围、IRQ路由、PCI设备列表等信息，是后续生成板级配置和编译的基础。把Board Inspector跑完，把输出的XML保存好，后续编译要用。

第三步，准备编译环境。ACRN对构建机器的要求不算苛刻，Ubuntu 20.04/22.04 x86_64即可，需要安装git、make、gcc、python3等基础工具。需要特别注意的是，编译Hypervisor和Service VM内核都需要交叉编译工具链，不过因为目标就是x86，直接用系统的gcc编译即可，不需要额外装交叉工具。

3.2 编译安装：ACRN Hypervisor、Service VM内核与Device Model

整个编译流程可以拆成三条线：

1. 编译Hypervisor本体。下载acrn-hypervisor源码，进入目录后，用之前生成的board XML和一份scenario配置（描述哪些VM、分配多少内存和CPU等）运行配置工具生成配置文件，然后执行make BOARD=<board_name> SCENARIO=<scenario_name>。编译产物是build/hypervisor/acrn.bin和acrn.efi，前者是GRUB引导用的二进制，后者是给UEFI Shell用的EFI程序。

2. 编译Service VM内核。ACRN对Service VM内核有专门的要求，不能直接用发行版内核加参数——它需要开启一系列ACRN特有驱动（如CONFIG_ACRN_HSM、CONFIG_VFIO、CONFIG_VIRTIO等）。社区维护了一个acrn-kernel仓库，里面包含适合做Service VM的内核源码和默认配置。编译命令是常规的make defconfig再加自定义配置，最终生成bzImage。

3. 编译设备模型（acrn-dm）。这部分运行在Service VM里，负责模拟虚拟设备、创建User VM。它跟Hypervisor源码在同一仓库，编译命令在tools/acrn-manager和devicemodel目录下。产出包括acrn-dm、acrnctl等可执行文件，需要安装到Service VM的文件系统里，并设置好系统服务。

编译过程中最常见的报错是企业代理、依赖缺失、Python工具链版本不对。我的建议是严格按照官方文档的依赖清单装，别用老教程里的旧版Python。ACRN 2.0之后配置几乎全面转向ACRN Config Tool（基于Python的Web工具或命令行工具），它会根据board XML和需求场景生成scenario XML，再生成源码里的配置头文件。如果你跳过了配置工具，直接改misc/config_tools下的默认文件，编译大概率会失败——这个工具在2.0里已经是主流程，不是可选项。

3.3 创建并启动User VM：以Linux为例

Hypervisor和Service VM都是基础环境，真正跑起来的是User VM。通过acrnctl来管理，典型的步骤是：

• 把编译时生成的scenario.xml和board.xml拷贝到Service VM的/etc/acrn/目录。
• 用acrnctl add <device_model_settings.xml>注册一个VM实例。这个XML描述了User VM的CPU、内存、磁盘镜像、网络、串口等配置。
• 启动前把Guest镜像（比如一个装了测试用Linux的qcow2或raw镜像）放到指定目录，设置好VirtIO相关参数。
• 执行acrnctl start <vm_name>，然后用acrnctl list查看VM状态。

如果一切正常，User VM的串口输出会显示Guest内核启动信息，最后弹出登录提示。这时候你可以通过分配到的虚拟网卡SSH进去，也可以直接在串口控制台操作。以我自己常用来实验的Linux Guest为例，启动时间大约几百毫秒到一两秒，具体取决于内核大小和磁盘镜像类型。

有一个容易忽略的细节：acrn-dm默认会把User VM的虚拟GPU输出重定向到VNC或PTY，如果你配置的时候没有打开图形，启动后看不到画面，只能通过串口登录。需要图形界面的话，要在acrn-dm启动参数里加-s 2,svga之类的配置并指定VNC端口。图形性能跟物理GPU直通是两码事，如果User VM需要3D加速，走VirtIO GPU效果一般，最好把真实GPU直通进去。

3.4 验证部署：确认Hypervisor接管了硬件

部署完第一件事是验证Hypervisor真的是Type-1跑在裸机上，而不是Service VM自己在跑。检查方法：

• 启动日志里看ACRN Banner。Hypervisor启动时会在屏幕上打印版本信息，比如ACRN Hypervisor 2.0字样，然后才有了Service VM的Linux内核启动日志。
• 在Service VM里执行ls /dev/acrn_hsm，这个字符设备存在说明Hypervisor的HSM（Hypervisor Service Module）驱动正常工作。
• 执行cat /proc/acrn，能看到Hypervisor的系统信息。
• 用acrnctl list看到所有已创建的虚拟机和它们的状态。

正确配置下，dmesg里还能看到Service VM启动阶段，HSM驱动注册成功、与Hypervisor建立通信的日志。如果HSM没起来，多半是内核config缺了CONFIG_ACRN_HSM，回头重新配内核。这类验证步骤看起来简单，但在实际项目里非常管用——我们曾经遇到过Hypervisor没接管、其实整机只是Service VM裸跑的尴尬情况，最后就是靠这些检查暴露出来的。

4. 横向对比：ACRN、KVM/Xen、Jailhouse和VMware在IoT场景的真实差距

选型这件事，不能只看ACRN一个方案。如果你在给IoT项目选虚拟化底座，大概率会遇到几个候选：KVM（Xen也可以算一类，但原理类似）、Jailhouse、VMware。它们之间的差距不是“谁更好”，而是“谁适合哪个场景”。我自己的判断标准是：启动开销、确定性、管理成本、硬件平台依赖、生态成熟度这五个维度。

4.1 先说结论：不同Hypervisor适合不同形态的IoT设备

按设备类别来分，我的经验判断大致是：资源极其受限、需要极致实时性的单板设备，Jailhouse静态分区很合适，但它不提供设备模拟，VM里只能用直通设备，灵活性差；需要在x86平台上同时跑多个操作系统、且这些系统之间互不信任、还要求实时性的场景，ACRN是主力方案；通用x86网关、边缘服务器，负载形态接近“小数据中心”，用KVM搭配libvirt更顺手，管理生态成熟；数据中心级的服务器虚拟化和灾难恢复，才轮到VMware这类商业产品出场。

这个区分，核心在于你对“确定性”和“资源效率”的权重。ACRN两头都要——它通过硬件直通和vCPU隔离保证确定性，也通过Type-1小体积保证资源效率。但它的代价是硬件平台绑定Intel，配置复杂，社区支持高度依赖官方板卡列表。项目周期里如果团队里没有熟悉ACRN配置流程的人，学习成本是实打实的。

4.2 关键维度对比表：实时性、启动开销、管理成本和生态

我用一张表把对比拉下来，方便做决策时直接参考：

从这个表能看出，没有银弹。ACRN的独特位置在于“Type-1 + 强实时 + 设备模拟灵活性”这个组合——Jailhouse虽然实时强但没有设备模拟，KVM虽然灵活但确定性弱且开销大，Xen在企业级成熟但面向IoT的工具链不如ACRN完备。

4.3 什么时候别用ACRN

把反例说清楚，比推ACRN强一百倍。我在实际选型里总结出几个“别用ACRN”的信号：

• 平台不是Intel x86，或者板卡不在ACRN官方支持列表上。ACRN的板级支持依赖配置库，新板卡需要你自己跑Board Inspector、手写scenario，不是不能做，但工作量远大于用主流发行版Linux跑KVM。
• 需要频繁创建、销毁、迁移虚拟机。ACRN的管理工具偏静态化，scenario配置在部署时基本定死，动态迁移能力很弱。如果负载形态像“云”，直接用KVM。
• 团队对实时性没有硬指标，只是想要“多个系统互不干扰”。这种场景KVM加libvirt已经很成熟，没必要为ACRN的复杂度付出学习成本。
• 需要图形化管理和集中监控。ACRN没有VMware vCenter那套东西，虽然能用Prometheus等辅助监控，但便利性差距明显。

5. 部署与调优中的实测心得：五个高频问题和我的解决方式

最后这部分是我在多个真实项目中反复踩坑总结出来的。ACRN部署起来比KVM繁琐不少，而且文档经常滞后于代码，很多问题不实际操作根本碰不到。我挑五个出现频率最高的，逐个讲清楚问题现象、根因和解决办法。

5.1 编译阶段最常见的板级配置错误

很多人第一次编译ACRN时，遇到的是make BOARD=xxx直接报“Board config not found”。原因几乎都是Board Inspector生成的XML和scenario配置没有正确放到源码的配置文件目录。ACRN 2.0之后，正确流程是用config tool先加载board.xml，再设定VM个数、CPU亲和性、内存大小、设备直通项，然后导出scenario.xml，最后用这两个文件调用代码生成器，打出配置头文件。跳过这一步直接改misc/config_tools/board_config下的默认文件，编译只会得到一堆莫名其妙的报错。

另一个高发错误是内存预留不足。Hypervisor和Service VM共享物理内存，但Service VM内核启动时需要一段连续内存跑DMA和中断表；如果scenario里给Hypervisor预留的内存太小，启动时内核直接panic。我的建议是physical memory预留按照官方默认值再上浮一部分，特别是要跑大量VirtIO设备的场景，宁可多留几百MB也别省，等稳定后再慢慢优化。

5.2 设备直通失败：先查IOMMU和中断重映射

直通设备启动时显示“Failed to set up IOMMU”或者“passthrough device not found”，大多数时候不是ACRN配置错了，而是底层IOMMU没配好。排查顺序：先确认BIOS里VT-d确实开启——有些工控主板BIOS里有两层开关，第一层是“Intel Virtualization Technology”，第二层才是VT-d，漏开第二层只开第一层很常见。然后确认Service VM内核的CONFIG_IOMMU_SUPPORT和CONFIG_INTEL_IOMMU打开了，同时CONFIG_VFIO模块加载正常。最后看中断重映射，dmesg | grep -i irq里看到“DMAR-IR”说明中断重映射生效，否则直通设备的中断注入根本走不通。

我做过的几个项目里，有一个比较隐蔽的坑，是设备在PCI总线上的位置因为BIOS或内核枚举顺序变化导致直通配置里写的00:1f.6对不上实际设备地址。建议直通配置里用PCI BDF加供应商ID双重校验，别只写一个BDF。

5.3 实时任务的确定性：调度策略与pCPU隔离

用户VM的实时性调优，最有效的配置是把它的vCPU固定到物理CPU的特定核心上。具体做法是在scenario配置里，为实时User VM设置cpu_affinity为几个指定的pCPU，同时把Service VM的vCPU和VirtIO线程绑到另外的核心上，两道工序缺一不可——否则Service VM的VirtIO线程会抢实时VM的vCPU时间片，实时性照样崩。

我实测过一个案例：一个跑PREEMPT_RT的User VM做Modbus TCP主站轮询，不绑核时最坏周期抖动到5毫秒，绑核并配合HV调度优先级后，抖动压到了几十微秒，提升了两个数量级。这个效果不是因为频率变高，而是因为确定性出来了，Guest里的逻辑可以按更可靠的时序预算设计。这也是ACRN这类Type-1方案的核心价值所在。

5.4 升级到2.0后要注意的配置变化

如果你是从ACRN 1.x升级到2.0，改动最大的其实是配置体系的迁移。1.x时代大量的XML配置靠手工维护，字段含义零散；2.0开始ACRN Config Tool成为主流程，配置生成逻辑集中化，但相应地，很多旧版手写的scenario直接搬到2.0会失效，字段名和VM类型定义都变了，比如旧版vm_type字段里的SAFETY_VM、POST_STD_VM等在新版里有不同的枚举值，还包括新的内存映射配置要求。

升级时最稳妥的路径是：用新版Config Tool重新加载旧版board XML，对比原生模板生成新scenario，再逐一核对内存预留、设备直通、vCPU亲和性配置是否一样。不要偷懒直接沿用旧配置文件，这个时间省不得，否则启动阶段Hypervisor和各种VM的兼容性问题会在现场集中爆发。

5.5 如果只是评估，先跑官方预编译镜像再动手

如果你只是看ACRN能不能满足项目需求，我不建议一上来就自己编译全套。ACRN社区提供了官方支持的板卡和预编译镜像，比如UP Squared、NUC系列，镜像里已经配好了Hypervisor、Service VM内核和acrn-dm。先拿官方镜像在评估板上跑通User VM、验证网络和直通设备，确认关键指标能达到，再回到编译调优阶段。这能省掉至少两三天的踩坑时间。

如果手头的板子不在官方列表里，那就只能走全流程了——Board Inspector抓配置、Config Tool生成scenario、自己交叉编译Service VM内核、手动写UEFI引导项。这个过程的成本不算低，但也正是ACRN这类项目能给你的最大价值：所有东西的细节都摆在面前，你能完全掌控系统里每一行配置的意思，而不是对着一个黑盒猜。

最后再分享一个经验：ACRN的调试一定要先把串口日志留好。Hypervisor启动阶段、Service VM启动阶段、User VM启动阶段，三个阶段的日志通道是分开的，特别是Hypervisor自己崩溃时，屏幕可能只剩一串十六进制寄存器，这时候只能靠串口日志里的CRL信息定位问题。我习惯在所有板卡上提前引出UART调试口，这比在出问题时再想办法省太多事。