qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Attempt at Mac OS X acceleration using "Hypervisor.Fram


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Attempt at Mac OS X acceleration using "Hypervisor.Framwork"
Date: Thu, 12 Nov 2015 17:18:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


On 12/11/2015 15:39, Peter Maydell wrote:
> I think it would be nice to be able to support hardware acceleration
> on OSX hosts, and I think the official Apple hypervisor APIs for this
> are the right way to do that. The questions I have are:
>  * how much code are we going to end up with in QEMU to support that?
>    (I've been told that the Apple APIs are very basic and low level,
>    so a lot of the code that in KVM is in the kernel to handle irqchips,
>    instruction emulation, etc, would need to also be in QEMU for the
>    benefit of OSX. We could probably take a lot of that from KVM,
>    but then maintenance and tracking bugfixes that go into the kernel
>    code would be an immense pain in the future.)
>  * is the code going to come with somebody who will stick around and
>    help us maintain it for the long term?
>    (At the moment OSX is only a minimally supported platform for QEMU,
>    because so few of the core developers use it for day to day development,
>    so we don't have the capacity to take on maintenance of a lot of
>    new code without new people to help)
> 
> There doesn't look to be anything particularly problematic with
> the skeleton code in your patch, but I think it would be easier
> to judge how the design should look if we had a discussion of
> what the differences between the KVM API and the hypervisor
> framework API are, where that would need more code in QEMU and
> how we'd handle that.

It's completely different.  The KVM API is much more high-level, while
Hypervisor.framework exposes VMX directly with only a tiny C API on top.

It's not a lot of code if performance does not matter too much.  The
main complication would be support for dirty bitmaps, but apart from
that it would be very straightforward.  You do not need to support
anything that lacks extended page tables, and that alone makes things a
lot easier.

The other problematic issue is support for CPUID, which is a pain with
KVM as well.

I cannot contribute due to lack of hardware, but I'm happy to review the
patches and, when things break, suggest how to debug it and even prepare
small patches.

I think it's a very important feature for QEMU.  Speed is the #1 reason
why people use VirtualBox instead of QEMU.  Similarly, it would be nice
to support HAXM on Windows.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]