[Qemu-devel] OS-X hypervisor.framework support

[Qemu-devel] OS-X hypervisor.framework support

[Alex Bligh]

Is anyone working on support for hypervisor.framework (OS-X's equivalent to kvm as far as I can see)?

If not, I might have a go in my copious spare time (cough) and if anyone would be interesting in helping, or giving advice that would be great.

I note that:
  https://github.com/mist64/xhyve

has support for this, and its license is described as "BSD" (that's it). Is that Qemu GPL compatible? Though I suspect a clean implementation may be easier.

-- 
Alex Bligh

Re: [Qemu-devel] OS-X hypervisor.framework support

[Peter Maydell]

On 6 June 2016 at 13:29, Alex Bligh <alex@alex.org.uk> wrote:
> Is anyone working on support for hypervisor.framework (OS-X's
> equivalent to kvm as far as I can see)?

Not that I am aware of.

Previous discussion:
https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03086.html

> If not, I might have a go in my copious spare time (cough) and if anyone would be interesting in helping, or giving advice that would be great.
>
> I note that:
>   https://github.com/mist64/xhyve
>
> has support for this, and its license is described as "BSD"
> (that's it). Is that Qemu GPL compatible?

If you look at the actual source files they have the full
license text in them. It's 2-clause BSD, aka FreeBSD; the
FSF say it's GPL-compatible. We already have 3-clause BSD
in the tree and 2-BSD should be fine too.

thanks
-- PMM

Re: [Qemu-devel] OS-X hypervisor.framework support

[Daniel P. Berrange]

On Mon, Jun 06, 2016 at 01:29:47PM +0100, Alex Bligh wrote:
> Is anyone working on support for hypervisor.framework (OS-X's equivalent to kvm as far as I can see)?
> 
> If not, I might have a go in my copious spare time (cough) and if anyone would be interesting in helping, or giving advice that would be great.
> 
> I note that:
>   https://github.com/mist64/xhyve
> 
> has support for this, and its license is described as "BSD" (that's it). Is that Qemu GPL compatible? Though I suspect a clean implementation may be easier.

The source code file headers show a standard 2-clause BSD, which is
compatible with the GPL. So it is fine to incorporate BSD licensed
code in QEMU, as long as you preserve attribution & copyright notices

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] OS-X hypervisor.framework support

[Alex Bligh]

Peter,

On 6 Jun 2016, at 13:43, Peter Maydell <peter.maydell@linaro.org> wrote:

> Not that I am aware of.
> 
> Previous discussion:
> https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg03086.html

Thanks. Missed that due to "Framwork" spelling!

-- 
Alex Bligh

Re: [Qemu-devel] OS-X hypervisor.framework support

[Alex Bligh]

On 6 Jun 2016, at 13:29, Alex Bligh <alex@alex.org.uk> wrote:

> Is anyone working on support for hypervisor.framework (OS-X's equivalent to kvm as far as I can see)?
> 
> If not, I might have a go in my copious spare time (cough) and if anyone would be interesting in helping, or giving advice that would be great.
> 
> I note that:
>  https://github.com/mist64/xhyve
> 
> has support for this, and its license is described as "BSD" (that's it). Is that Qemu GPL compatible? Though I suspect a clean implementation may be easier.

I started having a go at this.

My thesis is that's easier to emulate the KVM API and translate it
to Hypervisor.Framework calls, than modify qemu everywhere so it
calls Hypervisor.Framework everywhere directly, because there are
so many calls to the KVM API. What I have therefore done is
written some code to intercept all the kvm ioctls. As all but
a couple of these were ALREADY sent through kvm_*_ioctl() (for
tracing I presume) this was pretty easy to do. If this works, then
any speed critical bits can be rewritten natively. This avoids
splattering HVF code everywhere across qemu, which would be
a complete pain to maintain. Essentially, one can carry on
writing for kvm, and the idea is that in general it will work
for HVF too.

You thus need to compile with --enable-kvm --enable-hvf (for
now). Confusing, yes it is a bit.

I've emulated enough ioctls (who knows whether the code actually
works) to get to the point where kvm_run is called (and translated
into an hv_vcpu_run) without an ioctl being errored. Of course it
doesn't actually work at this stage (my VM exit processing is, um,
non-existent - the idea was to translate this into the kvm_run
structure, probably), and it's complaining about a corrupt
VMCS at the moment.

Whilst I haven't (yet) demonstrated that this works, I think I have
demonstrated that if I can get it work, it's a viable approach.
Modifications outside hvf specific files are pretty minimal
(tens of lines).

A significant problem is that Hypervisor.Framework has about zero
useful documentation on how to use it. I suspect one is best
reading the Intel 64-ia-32 architectures software developer
system programming manual, and guessing how Apple might have
implemented it based on that. I got to the current point without
looking seriously at xhyve, though I think to cope with vmexits
I will have to compare and contrast that to qemu.

I'd be interested in comments as to whether this is useful / mad /
wrong approach / whatever.

Code at:
  https://github.com/abligh/qemu/tree/qemu-hypervisor-framework
(based on 2.6.0)

-- 
Alex Bligh

Re: [Qemu-devel] OS-X hypervisor.framework support

[Peter Maydell]

On 12 June 2016 at 17:37, Alex Bligh <alex@alex.org.uk> wrote:
> My thesis is that's easier to emulate the KVM API and translate it
> to Hypervisor.Framework calls, than modify qemu everywhere so it
> calls Hypervisor.Framework everywhere directly, because there are
> so many calls to the KVM API.

I'm not entirely convinced this is the right architecture.
We already support multiple different accelerators, ie
at least KVM and TCG, so adding another one for Hypervisor.Framework
seems like the obvious approach.

thanks
-- PMM