Re: [Qemu-devel] [PATCH] hax: Support for Linux hosts

[Alexandro Sanchez]

Hey Paolo,

> What's the advantage of HAXM when Linux hosts can just run KVM?

For end-users, it's true that there's several disadvantages and barely any
advantages: There's some guests run only on HAXM, since it can handle MMIO
accesses using BMI instructions ...and that's about it. :-) The HAXM API
also offers protecting/unprotecting arbitrary chunks of guest memory, which
has some advantages over KVM_GET_DIRTY_LOG. It's used in [1], but has not
been upstreamed yet.

For developers, there's few advantages over KVM that make work slightly
easier/simpler:
- No need to recompile+install a kernel, but just build+load a kernel
module, which takes few seconds, e.g. [2]. I'm aware of your kvm-kmod
(really helpful!), but Linux updates require patching it, which in turn
makes it incompatible with older Linux releases.
- Automated building, testing (and soon nightly builds as well).
- Extensive emulator tests [3] (generic virtualization tests also on the
way).
- Inspired by Bareflank, support for 3rd party "extensions". [4]

Of course, I'm aware that KVM is much more mature/compatible/performant
that HAXM and many other alternatives. My point is that it might be a bit
more comfortable to work with HAXM (and we are trying to improve this
further every day).

Another point concerns what I feel is the raison d'etre for HAXM:

There seems to be an unnecessary fragmentation of hypervisor APIs: KVM
(Linux), HVF (Mac), WHPX (Windows), which resembles the fragmentation of
graphics APIs. Afaik, no cross-platform type-2 hypervisor exists aside from
HAXM and Bareflank. This is fine for QEMU, since all major accelerators are
implemented, but other smaller projects might suffer from this. Of course,
we could wrap all APIs under a single userland library, but aside from
adding another layer of abstraction/translation, the underlying problem
persists: Each new feature needs to be re-implemented inside each
hypervisor (and HVF/WHPX are closed-source!).

Type-2 hypervisors don't *need* to be tightly coupled to a specific kernel:
If you look at HAXM, a thin platform-specific layer exists, the rest is
shared code. I believe that's much more convenient.

Cheers,
Alexandro

[1]
https://android-review.googlesource.com/c/platform/external/qemu/+/643674/
[2] https://travis-ci.com/intel/haxm/builds/91615353
[3] https://github.com/intel/haxm/blob/master/tests/test_emulator.cpp
[4] https://github.com/intel/haxm/pull/121


On Fri, Nov 16, 2018 at 1:53 PM Paolo Bonzini <address@hidden> wrote:

> On 14/11/18 14:04, Alexandro Sanchez Bach wrote:
> > Intel HAXM supports now 32-bit and 64-bit Linux hosts. This patch
> includes
> > the corresponding userland changes.
> >
> > Since the Darwin userland backend is POSIX-compliant, the
> hax-darwin.{c,h}
> > files have been renamed to hax-posix.{c,h}. This prefix is consistent
> with
> > the naming used in the rest of QEMU.
>
> What's the advantage of HAXM when Linux hosts can just run KVM?  I guess
> avoiding bitrot?
>
> Paolo
>