Document/discuss reason for deprecation and comment on future directions

[hgkamath]

• Firstly, a thank you to developers for their contributions
• Just a user, I noticed the deprecation message for AEHD on 20251113 84d47be
• The promise of AEHD was like a near KVM clone hypervisor, equally reliable, but for windows
  • AEHD hypervisor would have been useful to Android and Linux alike.
• Reasons why HyperV:
  • Microsoft seems intent on making HyperV the one and only hypervisor on windows, not only for VM use, but also for containerized virtualization based security, in addition to uses such as WSL. So disabling HyperV means also those Microsoft windows features that need HyperV will also not work
  • WSL on HyperV allows for Direct mounting of local host folders.
  • Potential for accelerated VM display via WSLg allowing for VM GUI-apps, as long as the GPU driver is at least WDDM-2.9 compliant
  • Less technically savvy Windows users may not understand implications of what it means disable HyperV and install a different hypervisor, hopefully correctly, by following the given instructions. By keeping them on HyperV avoids antagonizing those users.
  • If qemu on WHPX works just as equally good, and if the WHPX backend code in qemu is well maintained, then maybe there is no problem.
• Reasons why not HyperV:
  • Under wsl2, the wsl kernel does not include support for selinux, and so it follows Linux distributions on wsl run with selinux disabled.
  • Older GPU hardware with pre-WDDM-2.8 final GPU drivers, do not do WSLg. The qemu fork used internally by the Android emulator project has mechanisms such as gfxstream to make graphics work.
  • qemu support for HyperV/WHPX is a bit flake-y, there are some unpredictable whpx bugs in qemu that isn't seeing fixing because there are no presently active windows-developers on the qemu-project, only maintainers.
  • The wsl2 graphics system relies on dxgkrnl which is not upstreamed from wsl-kernel git-repo, where-as qemu's virtio-gpu + venus, virtio-vga are very cross platform
  • In wsl2, virtio protocol based para-virtualized host devices are not available.
  • The Windows-Home-edition-s do not advertise included hyper-V feature support. But there are batch scripts/commands to augment a Windows-Home OS to install the hyper-V framework packages. But then, the HyperV framework on Windows-Home editions is unsupported/untested. It is even more in bad support territory when upgrading to Win11 versions on older unsupported hardware that do not allow upgrading to Win11 unless installer/upgrade-checks are bypassed.
  • Potential for identical VM-OS development for VMs on Linux/windows.
  • Ideally HyperV on WinOS and kvm on Linux should head toward feature parity and convergence. But if not, an alternate hypervisor, safe guards against the potential for Microsoft to have the control to create unmitigatable feature divergence in hypervisor technology. In other words, avoid vendor lock-in.
• There are other projects like podman-machine, lima-vm that may have benefited from a 2nd windows hypervisor.
• If AEHD is being deprecated, then the patch set sent to qemu-project for AEHD hypervisor support, becomes moot.
  • I had used Intel-s hax hypervisor before HyperV/whpx which qemu-project sort-of supported. I never got to migrate to AEHD as the patches to qemu never went beyond the RFP stage. As I understood the RFP, AEHD had to use windows data structures and so changed many internals of the linux-kvm. If AEHD mimicked linux-kvm 100% so that a VM software such as qemu did not see any difference, then maybe qemu may have been able to reuse its linux-kvm host-side interfaces.
• As software such as hypervisor managers are tightly coupled with the OS, it is necessary to have company backing and finances to ensure driver-signing and passing the Windows Quality Labs Certifications, without which the secure-boot and driver verification in a given WinOS installation will also need to be disabled, which is not good for a user's machine and the technicalities involved are almost certain to deter all but a few niche users.
• Strangely Microsoft discontinued Windows subsystem for Android.
• Classes of users who will be most likely be impacted by discontinuation
  • 1.) Windows users with older hardware whose GPU drivers are pre WDDM-2.8.
  • 2.) Windows users who want the choice to avoid the HyperV eco-system for whatever reasons.
  • 3.) Windows users on the Windows Home Editions who want virtualization, but worried about non-support by MS.
  • 4.) Potential Linux VM users on windows who would want to use AEHD with a hypothetical upstream patched official qemu
  • Unsure about Windows users on arm processors, as presently they have no alternative.

So questions include

• Reasons why now it is considered that HyperV is adequate for android-emulator.
• Reasons why AEHD route is considered sub-optimal
• Chances of project being resumed
• Future directions and assurances

I think google and/or the volunteer developers should not drop this project, but keep progress going,