Beyond amd64 and arm64

Barn currently supports amd64 and arm64 Linux guests. QEMU can emulate more architectures, but each additional Barn target needs an image and a complete boot-and-operation contract. This design assessment, reviewed on 2026-11-08, separates the existing runtime policy from possible future targets.

Hardware acceleration follows the host ISA

For Barn’s current 64-bit guest targets, native virtualization uses the host’s instruction set: HVF on macOS and KVM on Linux. QEMU TCG translates instructions for a foreign guest architecture. Rosetta can translate Intel Linux applications inside an Arm Linux VM; it does not provide an Intel Linux VM on Apple Silicon. See QEMU’s emulation overview and Apple’s Linux binary translation guide.

Barn’s tiers describe release evidence. Native Darwin arm64 and Linux amd64 have the primary live acceptance coverage; Darwin amd64 and Linux arm64 remain Tier2 until equivalent physical-host evidence is recorded. All TCG profiles are Tier2. A binary that cross-compiles is not sufficient evidence to promote a runtime tier.

There are two image-specific restrictions: stock EL8 arm64 uses TCG on Apple Silicon because of its 64 KiB translation-granule requirement, and EL7 is limited to native Linux/amd64. An unexpected failure of native acceleration fails the operation rather than silently selecting TCG. The authoritative policy is in platform.go and selectRuntime.

Keep the complete emulated boot profile

The existing arm64 TCG profile uses qemu-system-aarch64, the virt machine, and cortex-a72. Barn’s arm64 images require UEFI, with a matching firmware code image and a writable per-VM variable store. The target emulator and firmware must be installed even when the host architecture differs; Linux setup currently plans native-host dependencies.

For amd64 guests on arm64 hosts, Barn explicitly uses tcg,thread=single to preserve the stronger x86 memory-ordering contract. Other emulated profiles use tcg,thread=multi. Increasing the vCPU count therefore does not imply more translation threads in every configuration.

QEMU’s virt documentation lists cortex-a72 as a 64-bit CPU and warns that the max model can change across QEMU versions. A prior Barn investigation observed a firmware hang with one max configuration and a successful boot with cortex-a72 plus explicit pflash code/vars. Because the firmware arguments also changed, that observation cannot isolate the CPU model as the cause. It supports retaining the tested profile while investigating any change with a controlled comparison.

Keep guest architecture explicit in inventory and catalog metadata. qcow2 metadata describes the disk container, not the guest instruction set. Selecting a foreign image requires both the correct image architecture and a matching runtime profile.

Each new architecture needs different boot assumptions

The following are QEMU integration candidates, not supported Barn values:

The machine and boot differences are documented by QEMU for pSeries, s390x boot devices, RISC-V virt, and LoongArch virt. All four candidates would use TCG on Barn’s current amd64/arm64 hosts. Native Linux hosts for those instruction sets would be a separate host-support project.

Distribution support has several levels: a released CPU port, an installer, a root filesystem, and a generic cloud disk. A candidate must identify which one is available, its immutable source and checksum, and whether its bootloader and cloud-init configuration match the selected QEMU machine. Do not synthesize a download URL by replacing the architecture in another file name. The image evidence workflow applies before any candidate enters the catalog.

Implementation boundary

Adding a name to the architecture parser would leave the rest of the product incomplete. A target needs coordinated changes in:

• Platform and image schemas: canonical architecture names, aliases, validation, catalog entries, and release tier. Existing catalog readers reject unknown fields and unsupported architectures, so the rollout also needs an explicit compatibility policy for older clients.
• QEMU invocation: executable, machine, CPU, firmware/boot method, console, disk and NIC transports, and QMP identity.
• Guest initialization: seed delivery, user and key setup, interface naming, data-disk detection, and filesystem support.
• Host preparation: dependency packages, minimum QEMU capabilities, preflight diagnostics, and available firmware.
• Lifecycle operations: cold boot, SSH readiness, stop/start, resize capabilities, persistent disks, recreation, cancellation, and interrupted-operation recovery.

The existing entry points are internal/platform, internal/qemu, internal/cloudinit, internal/setup, and the image pipeline.

Acceptance for a new target

Start with one generic cloud image per candidate. Record its source and digest, QEMU version, full launch profile, and firmware. In a fresh temporary data root, verify cold boot, the expected uname -m, SSH identity, outbound traffic, host access, peer communication, data mounts, and restart. Then test recreate/destroy boundaries, preserved disks, and recovery after cancellation. Unsupported optional features need explicit diagnostics.

The research suggests evaluating ppc64le and s390x first, followed by riscv64 and then loongarch64. This order is an engineering hypothesis based on image availability and boot integration work, not a committed roadmap; a better validated image or a concrete user workload can change it.

Measure functional compatibility and performance separately. TCG is useful for installation, packaging, and architecture checks; database throughput and compilation benchmarks need measurements on representative native hardware before informing capacity decisions.