> why bother to learn to manage this? Even if primarily adopted by existing Microsoft customers familiar with Hyper-V, this would benefit Xen, KVM and any Linu

> why bother to learn to manage this? Even if primarily adopted by existing Microsoft customers familiar with Hyper-V, this would benefit Xen, KVM and any Linux distro running on the same hardware targets. If a theoretical HHQL motivates OEMs to prove that Linux drivers work in a Hyper-V root partition on new hardware, with driver fixes upstreamed to the Linux mainline kernel, then everyone wins. There is also ongoing work for nested virtualization, to enable KVM, Xen or Hyper-V to be a bare-metal (L0) or a nested (L1) hypervisor, e.g. in a cloud environment where the bare-metal hypervisor cannot be changed by customers. These interoperability improvements increase hardware support for hypervisors, which can then compete at multiple architectural layers. Users can choose based on optimization of the HL0-HL1-VM-App stack which works best for their specific workload.