超越 amd64 与 arm64
Barn 当前支持 amd64 与 arm64 Linux 客机。QEMU 可以模拟更多架构，但每个新增 Barn 目标都需要镜像和完整的启动、操作契约。本设计评估复核于 2026-11-08，区分已有运行时策略与未来候选架构。
硬件加速跟随宿主指令集
对于 Barn 当前的 64 位客机，原生虚拟化使用宿主指令集：macOS 使用 HVF，Linux 使用 KVM；跨架构客机由 QEMU TCG 翻译指令。Rosetta 可以在 Arm Linux VM 内翻译 Intel Linux 应用，但不能在 Apple Silicon 上提供 Intel Linux VM。详见 QEMU 模拟说明与 Apple Linux 二进制翻译指南。
| 宿主 | amd64 客机 | arm64 客机 | 当前原生运行发布证据 |
|---|---|---|---|
| macOS arm64 | TCG | HVF，受镜像兼容性限制 | Tier1 |
| macOS amd64 | HVF | TCG | Tier2 |
| Linux amd64 | KVM | TCG | Tier1 |
| Linux arm64 | TCG | KVM | Tier2 |
Barn 的 tier 表示发布证据等级。原生 Darwin arm64 与 Linux amd64 有主要的真机验收覆盖；Darwin amd64 和 Linux arm64 在补齐同等真机证据前仍为 Tier2。所有 TCG 配置也属于 Tier2。二进制交叉编译成功，不足以提升运行时的证据等级。
另有两条镜像限制：原版 EL8 arm64 因要求 64 KiB 地址转换粒度，在 Apple Silicon 上使用 TCG；EL7 仅限原生 Linux/amd64。原生加速发生预期外故障时，操作会失败，不会静默改用 TCG。实际策略以 platform.go和 selectRuntime为准。
保留完整的模拟启动配置
现有 arm64 TCG 配置使用 qemu-system-aarch64、virt 机器与 cortex-a72。Barn 的 arm64 镜像需要 UEFI，使用匹配的固件代码和每台 VM 独立可写的变量存储。即使宿主架构不同，也必须安装目标模拟器与固件；Linux setup 当前按宿主架构规划依赖。
arm64 宿主运行 amd64 客机时，Barn 显式使用 tcg,thread=single，以保留 x86 更强的内存顺序契约；其他模拟配置使用 tcg,thread=multi。因此，增加 vCPU 数量并不总意味着增加翻译线程。
QEMU 的 virt 文档将 cortex-a72 列为 64 位 CPU，并说明 max 模型可能随 QEMU 版本改变。此前 Barn 调查中，一组 max 配置停在固件阶段，而使用 cortex-a72 和显式 pflash code/vars 的配置成功启动。因为固件参数也变了，这项观察无法单独证明 CPU 模型是原因；应先保留已测试的配置，再通过控制变量的比较调查变更。
客机架构应在清单和目录元数据中显式记录。qcow2 元数据描述磁盘容器，无法识别客机指令集。选择异架构镜像时，镜像架构和运行时配置必须同时匹配。
每种新架构都有不同的引导条件
下列是 QEMU 接入候选，还不是 Barn 支持的参数值：
| 候选架构 | QEMU 目标与机器 | 需要建立的启动契约 |
|---|---|---|
ppc64le |
qemu-system-ppc64、pseries |
小端客机；SLOF 或已验证的 VOF/直接内核路径；pSeries 控制台和设备 |
s390x |
qemu-system-s390x、s390-ccw-virtio |
CCW/virtio 设备与显式 bootindex，替换 PC 式引导假设 |
riscv64 |
qemu-system-riscv64、virt |
OpenSBI/U-Boot 或已验证的 EFI 路径；设备树、CPU 扩展与串口 |
loongarch64 |
qemu-system-loongarch64、virt |
经过验证的 CPU 模型，例如 la464，以及匹配的 EDK2 固件和客机镜像 |
机器与引导差异见 QEMU 的 pSeries、s390x 引导设备、RISC-V virt与 LoongArch virt文档。这四种候选在 Barn 当前 amd64/arm64 宿主上都需要 TCG；支持对应指令集的原生 Linux 宿主则是另一项工程。
发行版支持分为正式 CPU 端口、安装介质、根文件系统和通用云盘等层次。候选必须说明实际提供哪一种、固定来源与摘要，以及其引导程序和 cloud-init 配置是否匹配选定的 QEMU 机器。不能替换另一个文件名中的架构来拼出下载地址。候选进入目录前，应先完成镜像证据核查。
实现边界
只在架构解析器里增加一个名字，产品的其他部分仍不完整。每个目标都需要协调修改：
- 平台与镜像 schema：规范架构名、别名、校验、目录条目和发布等级。现有目录读取器会拒绝未知字段和不支持的架构，发布方案还需明确旧客户端的兼容策略。
- QEMU 启动参数：可执行文件、机器、CPU、固件/引导方式、控制台、磁盘和网卡传输方式，以及 QMP 身份。
- 客机初始化：seed 交付、用户和密钥、网卡命名、数据盘识别与文件系统支持。
- 宿主准备：依赖包、最低 QEMU 能力、预检诊断和可用固件。
- 生命周期操作：冷启动、SSH 就绪、启停、resize 能力、持久盘、重建、取消与中断恢复。
现有实现入口包括 internal/platform、internal/qemu、internal/cloudinit、internal/setup和镜像流水线。
新增架构的验收
每个候选先选一份通用云镜像，记录来源、摘要、QEMU 版本、完整启动配置与固件。在全新临时数据目录中检查冷启动、预期的 uname -m、SSH 身份、出站流量、宿主访问、客机互通、数据挂载和重启，再测试 recreate/destroy 边界、持久盘保留和取消后的恢复。不支持的可选功能应给出明确诊断。
研究建议先评估 ppc64le 与 s390x，再评估 riscv64 和 loongarch64。这个顺序是依据镜像供给与启动接入工作量提出的工程假设，不是已承诺的路线图；更成熟的镜像或明确用户负载都可以改变顺序。
功能兼容和性能要分别测量。TCG 适合安装、打包和架构检查；数据库吞吐与编译基准需要在有代表性的原生硬件上测量，才能用于容量判断。