
Android Emulator – AMD Processor and Hyper-V Support - el_duderino
https://android-developers.googleblog.com/2018/07/android-emulator-amd-processor-hyper-v.html
======
jstarks
This is enabled by some new APIs we've been working on in Windows:
[https://docs.microsoft.com/en-
us/virtualization/api/](https://docs.microsoft.com/en-us/virtualization/api/).
These allow third-party use of the Windows hypervisor from unprivileged user-
mode processes (such as qemu). This is similar in spirit to KVM's ioctl
interface and macOS's Hypervisor Framework.

~~~
AceJohnny2
> _and macOS 's Hypervisor Framework_

Tangentially and asking the crowd:

What products on the market use macOS's Hypervisor Framework? Virtualbox
apparently doesn't [1], but Docker For Mac does [2]...

Edit: and QEMU added experimental support in 2.12 [3], released in April

[1]
[https://www.virtualbox.org/ticket/14217](https://www.virtualbox.org/ticket/14217)

[2] [https://docs.docker.com/docker-for-mac/docker-
toolbox/](https://docs.docker.com/docker-for-mac/docker-toolbox/)

[3]
[https://wiki.qemu.org/ChangeLog/2.12#Host_support](https://wiki.qemu.org/ChangeLog/2.12#Host_support)

~~~
ungzd
There was Veertu Desktop, but seems that it's dead project now.

------
izacus
It's worth mentioning that the AVD (emulator) always worked on Linux - it uses
KVM there and has no problems with AMD chips.

The issue was on Windows (and macOS) where it used Intel HAXM which obviously
didn't work with AMD cores.

~~~
merb
> The issue was on Windows (and macOS) where it used Intel HAXM which
> obviously didn't work with AMD cores.

there weren't really that many "official" mac products with amd.

------
AlexAltea
Microsoft's WHPX is closed source: we are stuck with an incomplete instruction
emulator, no guest debugging support and other shortcomings. All of this
locked to a single host OS. Same thing goes for Apple's HVF. Each vendor seems
to care only about their own software and hardware.

I'm afraid that the ecosystem of hypervisor APIs are going the same way as
with graphics APIs, e.g. _thanks_ to Direct3D and Metal. I believe we should
disregard such APIs in favor of cross-platform open alternatives such as
Intel's HAXM: Support for Linux and AMD SVM is planned on my side, as it
serves as basis for my PS4 LLE emulator.

~~~
jstarks
I just want to point out that you are free to use your own, more complete or
faster instruction emulator with WHP. We exposed an API for the one we use in
Hyper-V to make WHP easier to use out of the box, but it has no special
advantages or hooks into our hypervisor.

I’m curious what you mean about no guest debugging support. Also curious about
the other shortcomings so that we can prioritize appropriately. We have only
just shipped our first version.

On API divergence, it’s an interesting point. MacOS, Windows, HAXM, and KVM
all have slightly different philosophies about what a hypervisor should do.
Maybe over time we can work toward more convergence.

~~~
AlexAltea
_> I just want to point out that you are free to use your own, more complete
or faster instruction emulator with WHP._

True. This is an unimportant rant on my side, since it would be nice to have a
complete emulator out-of-the-box. But it's true it can be solved in userspace
(EDIT: now I wonder how could we inject exceptions back into the guest, should
they occur during emulation in userspace).

 _> I'm curious what you mean about no guest debugging support._

This would allow the host to introduce software/hardware breakpoints and
single-stepping through the guest. This is extremely relevant to debug
bootloaders/microkernels, or in my case, closed-source kernels that do not
support debugging. Some hypervisors, e.g. KVM (and soon HAXM), support this:
check "KVM_DEBUG_GUEST" at
[https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt](https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt)

 _> Also curious about the other shortcomings so that we can prioritize
appropriately._

The API provides no way to add/override/hook arbitrary MSRs while handling
guests's rdmsr/wrmsr instructions, or override CPUID leaves/subleaves. This is
required to run certain kernels are designed to run in specific x86
processors. Of course, most hypervisors lack this feature and I understand
that WHPX is fairly recent so I'm not complaining about the lack of it. My
issue is rather that closed-source implementations are not helpful for
researchers since shortcomings like these means the whole library is no longer
usable for us. Comparatively adding such features to (say) KVM or HAXM takes
just few hours.

Also, don't get me wrong. I feel it's incredibly valuable having finally an
API allowing developers benefit from Hyper-V in userland. I'm just concerned
about the current trend of hypervisor APIs, as every vendor eventually just
ships a closed hypervisor library for its own platform, and developers have to
put up with 5 different ways of doing the same thing.

(PS: I've invested quite some time on HAXM, but I'm __not __affiliated with
Intel in any way)

~~~
comex
> The API provides no way to add/override/hook arbitrary MSRs while handling
> guests's rdmsr/wrmsr instructions

Isn’t that what this is for?

[https://docs.microsoft.com/en-
us/virtualization/api/hypervis...](https://docs.microsoft.com/en-
us/virtualization/api/hypervisor-platform/funcs/msraccess)

Or are you looking for a higher-level API or something?

edit: and for CPUID:

[https://docs.microsoft.com/en-
us/virtualization/api/hypervis...](https://docs.microsoft.com/en-
us/virtualization/api/hypervisor-platform/funcs/cpuidaccess)

~~~
AlexAltea
Yes, that's exactly what I was looking for! I might overlooked it last time I
checked around May (was that documented at that time?). Thanks a lot for
pointing it out. :-)

~~~
jstarks
Yes, I was frantically adding some of these features at the end of the
release, so the docs came a little later :)

------
nedsma
Finally, I've been avoiding AMD processors for the better half of the decade
for exactly this reason. No reason anymore to continue so, especially in lieu
of the recent security issues that have mostly affected Intel CPUs. Great work
here Android team!

~~~
m-p-3
And they really catched up on Intel performance-wise.

------
LyalinDotCom
This is great stuff, I am so happy we've gotten this support on Windows when
Hyper-V is there. Kudos to everyone involved across borders that made it
happen.

FYI for anyone using Visual Studio & Xamarin, we've added support for this in
Visual Studio 2017 15.8 Preview 1 or higher with the Mobile development with
.NET (Xamarin) workload installed.

Miguel posted details in this blog post:
[https://blogs.msdn.microsoft.com/visualstudio/2018/05/08/hyp...](https://blogs.msdn.microsoft.com/visualstudio/2018/05/08/hyper-
v-android-emulator-support/)

Happy coding folks.

(disclaimer - I work at Microsoft)

------
matchbok
Still doesn't solve the core problem with the Android emulator - performance.
Android needs a "simulator", not an emulator running the entire stack. iOS
handles this wonderfully.

~~~
bitmapbrother
>Still doesn't solve the core problem with the Android emulator - performance

When was the last time you used the emulator?

~~~
brokenmachine
I'm not OP, but I last used it a couple of years ago and it was pretty slow (I
was using an i5-2500).

Has it improved markedly recently, and if so, how?

~~~
bitmapbrother
It now uses Intel's HAXM on Windows to increase performance tremendously. It
also allows for the saving of snapshots to launch the emulator almost
instantly.

