Asterinas 0.19.0: self-built kernel, Intel VMX-based support

Build memory held by the file cache

Testing this build path requires sufficient resource headroom. Asterinas Book requires an x86-64 Linux host with about 50 GiB of free disk space. The host needs KVM, the Linux feature that runs VMs with hardware acceleration. The outer Asterinas VM running on that host is allocated 40 GiB of memory and 4 virtual CPUs.

The documentation reports that memory use reaches about 31 GiB by the end of the kernel build. One cited cause is the failure to reclaim file cache even when memory comes under pressure. Data retained in the cache for reuse when files are read again competes with the memory and space needed for the build. In the documented configuration of 32 GiB of memory and 8 virtual CPUs, memory also ran short near the end of the build.

The two configurations vary in both memory and CPU count, so this is not a comparison of memory alone. The roughly 31 GiB usage figure is also difficult to attribute solely to the memory required by the compiler itself. Separately from the successful self-build, the lack of cache reclamation appears to constrain whether the build can run when memory is tight.

The gap between VMX support and /dev/kvm

Intel VMX support in this release provides a foundation for running guests with the CPU's hardware virtualization features. The project says it implemented guest CPU state management, EPT for mapping guest memory addresses to the host's physical memory, and VM-exit paths that return control from a guest to the host.

The OSTD framework handles low-level functionality for privileged instructions, while the kernel handles higher-level execution policy. This foundation and the KVM-compatible /dev/kvm interface used by tools such as QEMU are nevertheless at different implementation stages.

Asterinas Book states that Asterinas does not provide KVM yet, so nested VMs run through QEMU software emulation. An outer Linux host running Asterinas with KVM and Asterinas providing hardware acceleration to an inner VM are separate forms of support.

A hypervisor RFC approved on August 5, 2026, contains a design for a KVM-compatible interface. Approval of the design alone does not establish that the interface was implemented in this release.

Nested-VM validation covers booting only

Nested QEMU runs with networking and display output disabled because it cannot open the required listening sockets inside Asterinas. The nested VM prints a successful boot message and exits, but the documentation says that the make run_kernel command used to launch it still does not return.

The Nix build inside Asterinas also runs as root, an account with administrative privileges. It does not use a sandbox to isolate the build in a separate environment because the required isolation feature is unsupported.

This provides evidence that a substantial set of development tools runs on Asterinas, but it does not validate a general nested development session or an isolated multi-user build. If the resource requirements are met, this can serve as a starting point for examining the self-build path.

Time is another constraint. The documentation gives an installation time of about 30 minutes and says that the first build can take more than 1 hour depending on host performance.

Verifying a nested boot after preparing the development shell

The commands below assume that the full installation and build procedure documented in Asterinas Book has been completed. The sequence is to prepare a development shell inside an outer VM with 40 GiB of memory, build the kernel, and then verify a nested boot with the following command.

make run_kernel \
  ENABLE_KVM=0 \
  NETDEV=none \
  QEMU_DISPLAY=none \
  MEM=2G \
  AUTO_TEST=boot

ENABLE_KVM=0 disables hardware acceleration; NETDEV=none and QEMU_DISPLAY=none disable networking and display output. MEM=2G sets memory for the inner VM, and AUTO_TEST=boot selects the boot test.

The documented success message is "Successfully booted." Alongside it, the documentation notes that even if the nested VM exits afterward, the outer make command still does not return.