All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Assaf Gordon <assafgordon@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] Attempt at Mac OS X acceleration using "Hypervisor.Framwork"
Date: Thu, 12 Nov 2015 17:18:46 +0100	[thread overview]
Message-ID: <5644BBE6.7030808@redhat.com> (raw)
In-Reply-To: <CAFEAcA-=QzWGCgxPLaSW+vMEFQLT0YTyn+O-bMa9F-i1cohacA@mail.gmail.com>



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	other threads:[~2015-11-12 16:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 10:49 [Qemu-devel] Attempt at Mac OS X acceleration using "Hypervisor.Framwork" Assaf Gordon
2015-11-12 14:39 ` Peter Maydell
2015-11-12 16:18   ` Paolo Bonzini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5644BBE6.7030808@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=assafgordon@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.