3 ms·

If this reaches production status (e.g. with a new Hyper-V Hardware Qualification List and HHQL logo program like WHQL), it could be the biggest news for Linux

If this reaches production status (e.g. with a new Hyper-V Hardware Qualification List and HHQL logo program like WHQL), it could be the biggest news for Linux since Dell started shipping a laptop with pre-installed Linux. Such a logo program could provide OEMs with a test suite for Hyper-V with Linux hardware drivers, which means Microsoft could start contributing test cases to upstream Linux projects like CKI. Most importantly, a Hyper-V for Linux logo qualification program could require that OEM/ODMs pass HHQL before shipping supported hardware, when they still have engineering resources allocated for system and device firmware fixes. In short, Hyper-V for Linux has the potential for positive ripple effects throughout the supply chain for Linux "secured core" hardware. When combined with WSL2, Direct X paravirtualized graphics for Linux, and Azure Sphere (based on OpenEmbedded/Yocto), it's a major endorsement for Linux and the flexibility of Type-1, CPU-assisted virtualization pioneered by open-source Xen. The Microsoft Linux license for IoT/embedded devices includes support for 10+ years of security updates, which will hopefully extend OEM firmware support timelines for edge hardware, https://www.platformsecuritysummit.com/2019/speaker/seay/ https://www.platformsecuritysummit.com/2019/speaker/seay/ > This talk will cover ... device security from the chip to the Linux kernel, user application isolation, network communication, cloud interaction, and what it takes to keep a system secure for 13 years.

likesftereppl99 6y ago
Ok, sure. Given Xen is battle tested at scale and k8s/etc for microservices, why bother to learn to manage this?
- transpute 6y ago
  > 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.

likesftereppl99 6y ago

Ok, sure. Given Xen is battle tested at scale and k8s/etc for microservices, why bother to learn to manage this?

transpute 6y ago
> 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.