feat(kernel): adopt the arcbox microvm kernel on x86_64 (v0.0.24) - #50
Conversation
… pins to v0.0.24 x86_64 switches from the stock Firecracker CI kernel (6.1.155, EOL 2026-09) to the arcbox microvm flavor: hardware-reduced ACPI boot with DSDT-enumerated virtio-mmio, ELF vmlinux artifact, requires Firecracker >= 1.7. The stale note claiming the switch needed VIRTIO_MMIO_CMDLINE_DEVICES is gone — that mechanism is deprecated by Firecracker and stays off in the kernel config. Both arches move to the v0.0.24 release together: the version string keys the immutable CDN path and the arm64 bytes changed with the rebuild, so the key must change with them.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Greptile SummaryThe PR adopts the arcbox v0.0.24 microVM kernel on x86_64 and updates arm64 to the corresponding rebuild.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| upstream.toml | Updates both kernel artifact pins to v0.0.24, adopts the arcbox x86_64 microVM kernel, and accurately documents compatibility with the pinned Firecracker v1.16.1. |
Reviews (2): Last reviewed commit: "fix(kernel): the Firecracker ACPI floor ..." | Re-trigger Greptile
There was a problem hiding this comment.
ℹ️ One factual correction inline, plus one cross-repo confirmation worth making before this reaches the CDN.
Reviewed changes — a single-file pin bump in upstream.toml touching only the vmlinux entry.
- x86_64 kernel source swapped — from the stock Firecracker CI kernel (
vmlinux-6.1.155on S3) toarcboxlabs/kernelv0.0.24'smicrovm-kernel-x86_64. - arm64 kernel moved to the v0.0.24 rebuild — same
microvmflavor, new bytes, so the version key moves with it. - Version key bumped
0.0.23-microvm→0.0.24-microvm, re-keying the immutable CDN path for both arches. - Block comment rewritten — the stale claim that x86 needs
VIRTIO_MMIO_CMDLINE_DEVICESis replaced with an ACPI-discovery description.
Checks that came back clean: all three release URLs resolve (v0.0.24 arm64 + x86_64, and v0.0.23 arm64, so rollback = revert this pin genuinely holds); format = "binary" with no extract satisfies the src/upstream.rs validator for both sources; and no stale references to the old x86 kernel survive anywhere else in the repo. Firecracker's own docs/kernel-policy.md corroborates the PR's technical framing, including CONFIG_PCI=y being an ACPI-init requirement despite FC supporting no PCI devices.
ℹ️ The x86_64 discovery-mechanism switch has no validation on this side of the repo boundary
Worth being explicit about what this repo can and cannot prove. There are two distinct kernels in this pipeline: the outer guest kernel at asset/v{version}/{arch}/kernel (sourced by the download-kernel job, and the artifact tests/e2e/boot.rs::qemu_boots_x86_64_linux actually boots under QEMU), and the nested microVM kernel at bin/vmlinux/{version}/{arch}/vmlinux — which is the one this PR changes and which nothing here boots. The Firecracker invocation that consumes it, including the kernel cmdline, lives in the arcbox host repo.
That matters because the old x86 kernel accepted cmdline virtio-mmio discovery and the new one does not. Any virtio_mmio.device= arguments the host still passes on x86_64 are now silently inert rather than an error, so the failure mode is a microVM that comes up with no block or net device rather than a clear boot failure.
Technical details
# Confirm the host-side x86_64 Firecracker boot path before publishing
## Affected sites
- `upstream.toml:135-137` — x86_64 `vmlinux` source now resolves to an ACPI-only guest kernel.
- Out of repo: the arcbox host's Firecracker boot-source configuration and nested-microVM kernel cmdline.
## Required outcome
- Confirm the host does not depend on `virtio_mmio.device=` cmdline entries for x86_64 device discovery, since `CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=n` makes them a no-op rather than a hard error.
- Confirm the host-side Firecracker binary in the x86_64 deployment path is >= 1.8.0 (see the inline note on the stated floor). `upstream.toml:91` pins `1.16.1`, so this should already hold via the manifest — the risk is only a deployment that sources Firecracker some other way.
## Open questions for the human
- Has an x86_64 nested microVM been booted end-to-end against v0.0.24 from the host side, or does validation rest entirely on the boot smoke in `arcboxlabs/kernel` CI? Either answer is fine — it just determines whether this pin is safe to publish now or wants a host-side check first.ℹ️ Nitpicks
upstream.toml:114— the unchanged "Placed at/arcbox/kernel/vmlinuxinside the guest VM" line is now arm64-only framing, since the new lines 119-121 describe x86_64 as booting on bare-metal Linux KVM hosts. Worth a few words to keep the whole block consistent while you are editing it.
Claude Opus | 𝕏
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — one commit since the prior pullfrog review, correcting the stated Firecracker version floor in the vmlinux block comment.
- Firecracker floor corrected to
>= 1.8—upstream.toml:121now states the right minimum. x86_64 ACPI support landed in Firecracker1.8.0(PR #4428), so the compatibility contract this comment encodes is now accurate.
The correction is confined to the comment; version = "0.0.24-microvm" correctly stays put, since the version key tracks kernel bytes and no bytes changed. The author also noted the same off-by-one is being propagated as a fix to the platform bootkit PR and the kernel repo's config comments, which is the right blast radius for a contract stated in more than one place.
The cross-repo confirmation raised in the prior review — whether the arcbox host's x86_64 Firecracker boot path has been validated against an ACPI-only guest kernel — remains an open question for the human rather than a change wanted here.
Claude Opus | 𝕏
|
Post-merge note: v0.8.3 is poisoned — use v0.8.4. The kernel v0.0.24 release's automatic |

Completes the CORE-79 follow-up: the x86_64 microVM guest kernel switches from the stock Firecracker CI kernel (6.1.155 — its 6.1 line EOLs 2026-09-02) to the arcbox
microvmflavor from kernel v0.0.24.microvm-kernel-x86_64(22.1 MB ELF vmlinux, sha256819ce6ff…) — hardware-reduced ACPI boot, DSDT-enumerated virtio-mmio, CI-boot-smoked under Firecracker on KVM every build. Requires Firecracker ≥ 1.7 (ACPI support); the deprecated cmdline device discovery is off per FC's kernel policy.661246ed…). The version string keys the immutable CDN path, and the arm64 bytes changed with the rebuild, so both pins move together — per the version-key rule from feat: switch the microVM guest kernel to the arcboxlabs/kernel microvm flavor (CORE-79) #49's review.The stale comment claiming x86 needed
VIRTIO_MMIO_CMDLINE_DEVICESis corrected: five CI boot-smoke rounds + FC's owndocs/kernel-policy.mdestablished that ACPI is the supported discovery path andCONFIG_PCI(no devices, ACPI-init requirement) was the actual missing piece.