I really don't like that diagram. The folks doing serverless work at University of Wisconsin-Madison generally do a good job, but they really whiffed on that one.
I don't think there's a reasonable sense in which KVM/Qemu moves more functionality to the guest kernel than KVM/Firecracker does. Both depend on the guest kernel for VM setup (KVM), low-level virtualization operations (KVM), and doing the actual IO below their paravirtualized device drivers. On the other end, Linux containers don't have a guest kernel (unless you use some kind of library OS). So those boxes should collapse together. If you look at it one way, gVisor is a guest kernel, which depends on the host kernel in fundamentally similar ways to what Firecracker or Qemu do.
I took the diagram to just mean the whole guest, not just the kernel. In the qemu case, the guest has to interact with the bios and other emulated peripherals. Firecracker skips the whole bios layer so it does operate at a different layer
I really don't like that diagram. The folks doing serverless work at University of Wisconsin-Madison generally do a good job, but they really whiffed on that one.
I don't think there's a reasonable sense in which KVM/Qemu moves more functionality to the guest kernel than KVM/Firecracker does. Both depend on the guest kernel for VM setup (KVM), low-level virtualization operations (KVM), and doing the actual IO below their paravirtualized device drivers. On the other end, Linux containers don't have a guest kernel (unless you use some kind of library OS). So those boxes should collapse together. If you look at it one way, gVisor is a guest kernel, which depends on the host kernel in fundamentally similar ways to what Firecracker or Qemu do.