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