It's a niche use-case, but one of the things I've been curious about is nested virtualization using Firecracker as the outside VMM and KVM as the inner VMM (wit

It's a niche use-case, but one of the things I've been curious about is nested virtualization using Firecracker as the outside VMM and KVM as the inner VMM (with QEMU being the sole userspace process running in the Firecracker VM). This would make it possible to use Firecracker for whole-system virtualization, and run Windows. KVM-in-Firecracker is apparently technically possible and just works thanks to Linux' support of nested virtualization, but celebratory noises to that effect elicited a slightly freaked out response: https://github.com/firecracker-microvm/firecracker/issues/1721 https://github.com/firecracker-microvm/firecracker/issues/17... That issue only really covered the security impliciations of multiple KVM (QEMU) instances inside a given Firecracker instance though, which I can totally see as (strictly, pedantically) problematic. But if QEMU is literally the only thing running (besides an only-what's-necessary /init) in a given Firecracker instance, that sounds to me like I'd have the best of all the worlds (Firecracker's awesome security and hardware emulation) with verifiably no downsides, right? The only ramifications I can see are if the hardware acceleration involved in nested virtualization might represent a security vulnerability. Theoretically a practical attack would equivalently impact Firecracker-inside-Firecracker use cases as well, on the assumption that it would need to first break out of QEMU and then Firecracker, as opposed to *waves hands* doing something that punches all the way from the twice-VMM'd guest all the way out to the host because of a hardware fault. Such hardware issues are arguably unfixable though (insert standard paragraph about microcode updates here), so theoretically (from a software boundary correctness perspective) I should be good to go right?