On Fri, Mar 03, 2023 at 08:50:18AM -0800, Haitao Shan wrote: > On Fri, Mar 3, 2023 at 2:34 AM Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Thu, Mar 02, 2023 at 06:25:59PM -0800, Haitao Shan wrote: > > > The Android Emulator hypervisor driver is a hypervisor for Windows (7 > > > or later), made by porting the KVM from the linux kernel 4.9-rc7. Its > > > initial purpose was to support the Android Emulator on the AMD > > > platforms as the old name "Android Emulator Hypervisor Driver for AMD > > > Processors" suggested. Despite the name, Intel processors have been > > > supported ever since its first release. Since Intel dropped HAXM support, > > > the android emulator is switching from HAXM to AEHD. > > > > When HAXM was proposed for deprecation & removal from QEMU, the suggestion > > was that users should switch to Windows' native replacement WHPX, which > > QEMU already has support for. > > Sorry I was not aware of Intel's suggestion when HAXM was deprecated. > Is this a decision already, which shuts the door for any other 3rd party > hypervisors?
No, we're always open to new proposals. It merely means that it might be harder to justify why the new hypervisor is a net benefit for QEMU, when there is a competing solution supported by the OS vendor. > > What is the rationale for wanting to introduce a 3rd party hypervisor > > solution like AEHD, for the Android emulator, rather than just sticking > > with the standard WHPX hypervisor available for Windows ? IIUC, the > > Android emulator can already support WHPX according to these pages: > > > > https://developer.android.com/studio/run/emulator-acceleration > > > > https://learn.microsoft.com/en-us/dotnet/maui/android/emulator/hardware-acceleration?view=net-maui-7.0 > You are right. WHPX is supported by the android emulator. The reason for > supporting AEHD: > > 1. HyperV is a type-1 hypervisor, which does not coexist with other > hypervisors. > According to our data, there are both users who have to live with HyperV on or > with HyperV off. Those users depend on certain Windows features (or 3rd party > programs) that have to turn on or turn off HyperV. Offering AEHD allows us to > serve both types of users. This is the major benefit. I think this > argument is true > for upstream QEMU users as well. Yes, it is an akward situation if users cannot enable use of WHPX. I don't have any better suggestion in that scenario. > 2. Actually, AEHD started development before WHPX was added to the android > emulator. But porting/writing a new hypervisor just took lots of time. > In the middle, > Microsoft offered us WHPX. It could be the case that AEHD was never started if > WHPX had been offered one or two years earlier. However, we decided to > continue. > First, see reason 1. Second, at least at that time, WHPX was noticeably slower > than both HAXM and AEHD. Third, Microsoft clearly stated there would not be > any backporting of WHPX to older versions of Windows. And those using old > versions of Windows need a solution in addition to HAXM. FYI, from the QEMU POV, we only aim to support the two most recent major releases of Windows. At a technical level we've set the compilation baseline to Windows 8, but per the support policy we only really support Windows 10 and 11 right now. > 3. Compared with HAXM, which looks like the default solution when HyperV > must be off, AEHD supports both Intel and AMD. And according to user feedback > and our own tests, AEHD can support Windows 10. This was the reason > why I maintained a patched QEMU ever since 4.2.0 specifically for them. Yep, no disagreement that AEHD looks more useful for HAXM given the cross vendor CPU support. > 4. Although it is called Android Emulator hypervisor driver, it has nothing > that > is android specific. And I've seen the upstream QEMU successfully refactored > the > accelerator logic. This made adding a new hypervisor support less intrusive to > the main code base. I have a good will and intention to maintain what I > submitted if it could be approved by the community. I hope this does > not place (or > at least place very minimum) burden on the maintainers, should it be accepted. Ok, thank you. I don't have any specific requests / suggestion myself, but I see others replied wondering whether there's any sense is sharing code with the KVM driver in QEMU. Hopefully the QEMU KVM maintainers will comment with their views on the matter. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
