> afaik, loading the unikernel directly with `qemu -kernel` avoids that? (author here) Thanks for this. I believe you are correct, though I have not yet had a

> afaik, loading the unikernel directly with `qemu -kernel` avoids that? (author here) Thanks for this. I believe you are correct, though I have not yet had a chance to benchmark it. It seems like there are a few different "shortcuts" that pre-load the kernel into memory (like `qemu -kernel`) from different tools. For example, I know also of `kvmtool` used in the clear containers project[1]. I'm not sure if all of them choose multiboot[2] as their standard and it's not clear how much of a traditional boot could or should be pushed into the hypervisor. `kvmtool` prepares a 64-bit environment with the Linux "zero page" structure instead of multiboot. From a unikernel perspective I think this is an interesting question to ask, because typical CPU setup including page tables (direct map is common for such a simple kernel) and segment registers, etc. will likely all be boilerplate. It will almost certainly be faster to preload the CPU and memory than to do it at boot time. (At the cost of reducing the number of hypervisors that can boot the kernel) [1]: https://lwn.net/Articles/644675/ https://lwn.net/Articles/644675/ [2]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html https://www.gnu.org/software/grub/manual/multiboot/multiboot...