作者：*Daroc Alden* ，2026 年 5 月 5 日 

Steffen Eiden 等人最近发布的一组 补丁集 为在 s390 CPU 上实现硬件辅助模拟 Arm CPU 奠定了基础。该帖子的 第二版 修复了一些较小的问题，但变化不大。Arm 维护者对这些补丁表示欢迎，但仍需讨论如何构建两个架构之间的协作，以防止 Arm 端的维护性问题。当这些细节得到解决后，这些补丁将为在 s390 宿主机上以原生或接近原生的速度透明地运行基于 Arm 的虚拟机（VM）铺平道路。 

该功能的核心是 一个补丁，它增加了一条名为“启动 Arm 执行”（Start Arm Execution，SAE）的新 s390 指令。它的功能类似于 s390 上现有的“启动解释执行”（Start Interpretive Execution，SIE）指令，后者用于进入硬件辅助虚拟机，同时保持虚拟 CPU 状态与宿主机 CPU 分离。这两条指令都接收一个指向“控制块”的指针，该控制块描述了虚拟 CPU 应如何设置和进入。不同之处在于，SAE 指令的控制块将指令指针设置为包含 Arm 指令的内存块，并将其作为 Arm 指令（而非 s390 指令）进行解释。 

从理论上讲，这允许拥有足够新的、支持该功能的 s390 CPU 的用户直接运行 Arm 虚拟机。显然，在某些阶段必须将 Arm 机器码翻译为 s390 机器码，但 CPU 会在内部处理这一点。补丁集并未明确说明其具体的实现方式。 

在内核方面，虽然想法简单，但实现起来要复杂一些。当虚拟机调用其管理程序（Hypervisor）时，它们使用特定架构的接口进行调用。如果要在 s390 上不加修改地运行 Arm 虚拟机，s390 内核中的 KVM 代码需要能够解释 Arm 的超级调用（Hypercalls）。为了支持这一点，Eiden 的补丁集将接口定义和相关的头文件移动到了 include/uapi/arch/arm64/ 目录下，从而允许其他架构引用它们。有趣的是，这使得一些重复代码得以清理；这些补丁最终删除的代码行数比增加的还要多。 

然而，在这些补丁合并后，还有额外的工作要做。s390 架构还将增加用于操作 Arm 寄存器、处理中断等指令。Eiden 希望在未来几个月内与其余 s390 开发人员一起增加对这些功能的支持。 

针对该补丁集的反馈相对较少，但 Marc Zyngier 在咨询 Will Deacon 后给出了 一份详尽的回复。他们对这一努力表示支持，但担心将一些 Arm 特有的代码移动到共享目录会显得混乱，并可能干扰代码的可维护性。他们建议使用符号链接、相对路径或代码生成，以便让现有的 Arm 代码保留在原有的位置，同时又不会对 s390 代码造成不当限制。 

Eiden 在 回信 中解释说，他们最初尝试过对头文件使用符号链接，但担心这种方法会因为有些混乱而无法获得支持。部分代码也是自动生成的，重用了 Arm 代码中的 Makefile 规则。但他同意对使用符号链接的替代方案进行原型设计，并发布出来供对比。该补丁集已于 4 月 28 日发送，截至撰写本文时尚未收到任何评审意见。 

Zyngier 表示，一个更严重的担忧是 s390 如何跟上仍在不断演进的 Arm 虚拟机客户机 API。例如，有一些 CPU 漏洞缓解措施需要客户机的配合。当发现新漏洞时，Arm 会为所需的新接口分配一个超级调用函数编号，并由 KVM 实现它。s390 的代码可能也需要类似的处理，既要为新的 Arm 特有缓解措施添加存根（Stubs），又要与 Arm 合作添加任何所需的 s390 特有接口。不过，这些应该仅限于缓解措施，因为 Arm KVM 代码“坚持禁止使用任何特定于实现的指令或系统寄存器”，Zyngier 预计 s390 的代码也会这样做。 

Eiden 对此并不过度担忧，他表示该项目的一个主要目标是能够运行未经修改的 Arm 客户机，因此他和他的 s390 开发同行将把 Arm 代码视为事实标准。因此，他们没有计划引入 s390 特有的功能，也不会废除通常的流程。 

Zyngier 和其他 Arm 维护者由于可以理解的原因，对 s390 的细节并不熟悉。因此，Zyngier 和 Deacon 还请求在文档、测试和调试方面提供帮助，以确保对 Arm 代码的更改不会对 s390 产生不利影响。 

最后，我们认为两个项目如果能“交换俘虏”并在 MAINTAINERS 文件中设置交叉评审者，将对双方都有利。这样，KVM/arm64 将增加一名 s390 评审者，而 KVM/s390 也将增加一名 arm64 评审者。 

Eiden 欣然同意，并建议为 s390 交叉编译内核是一个很好的测试起点。他还提出可以提供 IBM 托管的 s390 虚拟机用于原生构建。Eiden 计划将 Arm 的持续集成测试分支加入 s390 的构建基础设施中，以便尽早发现任何破坏。他也认为交换维护者是有意义的，并已经在补丁系列的第二版中 将自己添加为 Arm KVM 评审者。 

Eiden 和 Zyngier 计划在 Linux Plumbers Conference（LPC）以及 Linux Storage, Filesystem, Memory Management, and BPF Summit（LSFMMBPF）上与其他 s390 和 Arm 内核开发人员会面。希望面对面的会议足以解决任何剩余的细节，既然每个人似乎都对这一变化感到满意，这很有可能实现。 

[ 感谢 Andi Holmes 将这一话题引起我们的关注。 ] 

LWN 评论概述：

这些评论探讨了跨指令集架构（ISA）执行的技术细节及其历史先例。一位读者回忆起 NEC V30 处理器，它作为一个 8086 的克隆芯片，却能进入 8080 模式来运行 CP/M，尽管 s390 与 Arm 之间在微架构和字节序上存在着比这更大的差异。另一位评论者推测，s390 CPU 可能并非在进行某种形式的指令翻译，而是拥有不同的解码器来驱动一个共享的后端。 

讨论中还提到了 Transmeta Crusoe 处理器，该处理器以其代码转换技术而闻名。针对该补丁集是否为“迟到的愚人节玩笑”的质疑（考虑到其发布日期为 4 月 2 日），有回复澄清了 s390 的现状。最后，一位用户指出这种技术其实并不罕见，现代 Intel 芯片在启动时就会在实模式（8086 模拟）、保护模式和长模式等不同的 ISA 模式之间切换，所有这些模式都共享同一个后端，这与文章中描述的 s390 方案有异曲同工之妙。 

全文完

关注了就能看到更多这么棒的文章哦～   
 LWN 文章遵循 CC BY-SA 4.0 许可协议。 

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～