linux: run embedded Firecracker with KVM

[dzbarsky]

Author: zbarsky-bot

Builds Firecracker 1.16.0 from source with rules_rs for ARM64 and x86_64, embeds Firecracker and the immutable VM files in linux-actiond, copies the immutable files to sealed memfds, and starts Firecracker with execveat. cas.ext4 remains the only persistent file; Firecracker attaches cas.ext4 and the runtime SquashFS as PCI virtio block devices and exposes REAPI through its Unix-vsock backend.

The x86_64 GitHub Actions job compares the LLVM llvm-tblgen build through Firecracker/KVM with the native Linux host. The ARM64 job builds the release binary because the GitHub ARM64 hosted runner does not expose KVM. PR #16 contains the QEMU/TCG implementation for a separate comparison.

Validated with one bazel build --config=remote -c opt command for both Linux release targets. The remote Firecracker tests and both tool test targets pass; //src:unit_tests still reproduces the pre-existing cache_service.test.batchReadBlobs returns data or not_found status ReadFailed on the remote worker.

[dzbarsky]

x86_64 Firecracker/KVM LLVM smoke from GitHub Actions run 27476089745:

Execution	Bazel elapsed	Wall elapsed	Total processes	Executed processes
actiond	256.334s	256.414s	2,079	1,998
Linux host	246.639s	246.735s	2,079	1,998

The actiond / Linux host Bazel elapsed ratio is 1.039x. Firecracker startup to gRPC readiness is 0.613s. Both measurements use the same Linux x86_64 musl target and host platform, the same warmup target, Bazel's default job count, and matching process counts. The actiond measurement runs first, so the host measurement may benefit from warmer host filesystem caches.

The ARM64 release build also passes. The GitHub ARM64 hosted runner does not expose KVM, so the ARM64 job is build-only.

For comparison, the QEMU microvm/TCG run on PR #16 is 3,084.336s actiond / 272.311s host (11.327x). Firecracker's actiond time is about 12x faster, but QEMU uses TCG and the measurements came from separate CI runs, so this is not a hypervisor-only comparison.

-zbarskybot

[dzbarsky]

Tested Firecracker virtio-pmem with ext4 dax=always using the same 8 GiB persistent cas.ext4 file and the same LLVM llvm-tblgen workload. Linux required CONFIG_NVDIMM_PFN=y, which selects CONFIG_ND_CLAIM; without CONFIG_ND_CLAIM, devm_namespace_enable() returns -ENXIO and /dev/pmem0 is not created.

CAS device	Run	actiond	Linux host	actiond / host	Executed processes
PCI virtio-blk	27477132157	287.837s	293.087s	0.982x	1,998 / 1,998
PCI virtio-pmem + ext4 DAX	27480307956	289.431s	274.500s	1.054x	1,998 / 1,998

The actiond leg changed by +1.594s (+0.55%), which is within the observed run-to-run variation and provides no measurable improvement. The host leg changed by -18.587s, so the ratio change should not be attributed entirely to PMEM. I removed the PMEM implementation and restored this branch to the successful virtio-blk revision 48f0cfd rather than retain additional kernel configuration and guest mount code without a measured benefit.

QEMU supports the equivalent configuration with memory-backend-file and virtio-pmem-pci. PR #16 currently uses microvm with PCI disabled, so testing QEMU PMEM would require enabling PCI or changing the QEMU machine configuration.

-zbarskybot