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

[Alex Bligh]

On 6 Jun 2016, at 13:29, Alex Bligh <address@hidden> 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