3 ms·
Mostly because that's not how the kernel is designed. While what you're saying is true, it would require a fundamentally different kernel design. The kernel a
by tristor 3y ago
Mostly because that's not how the kernel is designed. While what you're saying is true, it would require a fundamentally different kernel design. The kernel as it is today is designed to work on a variety of devices, not just VMs, so it behaves in a way in which it doesn't have specific knowledge of the device prior to initialization. To do what you're suggesting, the kernel would need to have a special mode where it supports injection of this information from the VM host in advance of initialization, and there's probably a bunch of possible security issues involved as well.
- anthk 3y agoNetBSD can just trim the kernel down to Virtio support and not much more.
- deleted 3y ago[deleted]
- alexey-salmin 3y agoYou don't need kernel support, just freeze it's state right after the boot and clone it afterwards. Boot time will be the setup of shadow page tables and other hypervisor structures at new offsets. Plus a few tricks to avoid reproducible RNGs.
- inkyoto 3y ago> […] freeze it's state right after the boot and clone it afterwards. You can't do that easily as devices can be attached, detached or reattached dynamically whilst the VM is running and when it is shut down. In lieu of the hardware / VM support for device trees, with the existing design, the kernel has to probe each device upon every boot.
- alexey-salmin 3y agoWell it's not an ordinary boot of course, it's a clone and the state on both side of the fence should be faithfully cloned including virtual devices. The guest kernel will have no way of knowing whether it was resumed once or twice. Applicability is limited, but works well to spin up serverless compute on-demand.