Skip to content

feat(kernel): adopt the arcbox microvm kernel on x86_64 (v0.0.24) - #50

Merged
AprilNEA merged 2 commits into
masterfrom
feat/microvm-kernel-x86
Aug 7, 2026
Merged

feat(kernel): adopt the arcbox microvm kernel on x86_64 (v0.0.24)#50
AprilNEA merged 2 commits into
masterfrom
feat/microvm-kernel-x86

Conversation

@AprilNEA

@AprilNEA AprilNEA commented Aug 7, 2026

Copy link
Copy Markdown
Member

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 microvm flavor from kernel v0.0.24.

  • x86_64: microvm-kernel-x86_64 (22.1 MB ELF vmlinux, sha256 819ce6ff…) — 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.
  • arm64: same flavor, moved to the v0.0.24 rebuild (sha256 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_DEVICES is corrected: five CI boot-smoke rounds + FC's own docs/kernel-policy.md established that ACPI is the supported discovery path and CONFIG_PCI (no devices, ACPI-init requirement) was the actual missing piece.

… 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.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

@greptile-apps

greptile-apps Bot commented Aug 7, 2026

Copy link
Copy Markdown

Greptile Summary

The PR adopts the arcbox v0.0.24 microVM kernel on x86_64 and updates arm64 to the corresponding rebuild.

  • Replaces the stock Firecracker x86_64 kernel with microvm-kernel-x86_64.
  • Updates both architecture-specific kernel URLs and the immutable version key to v0.0.24.
  • Documents the architecture-specific boot mechanisms and Firecracker >=1.8 requirement.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

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

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ 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.155 on S3) to arcboxlabs/kernel v0.0.24's microvm-kernel-x86_64.
  • arm64 kernel moved to the v0.0.24 rebuild — same microvm flavor, new bytes, so the version key moves with it.
  • Version key bumped 0.0.23-microvm0.0.24-microvm, re-keying the immutable CDN path for both arches.
  • Block comment rewritten — the stale claim that x86 needs VIRTIO_MMIO_CMDLINE_DEVICES is 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/vmlinux inside 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.

Pullfrog  | Fix all ➔Fix 👍s ➔View workflow run | Using Claude Opus𝕏

Comment thread upstream.toml Outdated

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ 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.8upstream.toml:121 now states the right minimum. x86_64 ACPI support landed in Firecracker 1.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.

Pullfrog  | View workflow run | Using Claude Opus𝕏

@AprilNEA
AprilNEA merged commit 0b259e5 into master Aug 7, 2026
18 checks passed
@AprilNEA
AprilNEA deleted the feat/microvm-kernel-x86 branch August 7, 2026 11:33
@linear-code

linear-code Bot commented Aug 7, 2026

Copy link
Copy Markdown

CORE-88

@AprilNEA

AprilNEA commented Aug 7, 2026

Copy link
Copy Markdown
Member Author

Post-merge note: v0.8.3 is poisoned — use v0.8.4. The kernel v0.0.24 release's automatic repository_dispatch rebuild fired at 11:18 UTC, before this PR merged (11:33), and published v0.8.3 to the CDN from pre-merge master — i.e. with the OLD 0.0.23-microvm pins. My explicit dispatch then updated the GitHub release assets from post-merge master, leaving the two channels inconsistent (CDN manifest 287efa3c… = 0.0.23 pins; GH release manifest cc87bc19… = 0.0.24 pins). Since CDN version paths are immutable, v0.8.3 stays as-is and v0.8.4 is the canonical release for this pin switch. Workflow-design follow-up: the kernel-release auto-trigger can race a pending pin PR; it should either target the PR's merge or gate on the pin matching the kernel tag it was triggered for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant