Post

@emaste I am wondering, what are the benefits? It's not that I'm saying it's irrelevant, on the contrary, what I'm trying to say is that I don't know enough of the ecosystem to fully grasp the achievement and be properly astonished.

@emaste

Has someone finally documented the ioctl interface for vmm?

Microsoft had a Linux kernel module that implemented the kvm APIs but passed them through to Hyper-V, so you could use Linux as the management domain or, if configured correctly, one Hyper-V VM could create others by delegating its own memory. I looked at doing the same thing for FreeBSD (in either direction: forwarding bhyve ioctls to Hyper-V, or providing kvm-on-bhyve from Linux) but the blocker was the complete lack of documentation of the vmm ioctls. The public interface was the bhyve command-line tool, which is why there are so many alternative things built on kvm and almost nothing on bhyve.

Microsoft also had an internal abstraction layer that papered over the differences between the Hyper-V APIs, KVM, and Apple’s Hypervisor.framework. These all provide roughly the same set of abstractions (start and stop VCPUs, map memory, handle page faults, deliver interrupts to VCPUs, and so on), so it was fairly easy to paper over the differences (which were things like some APIs create and launch VCPUs as a single operation, some as two: it’s easy to make the former look like the latter with a little bit of in-library state). But doing the same for FreeBSD was hard, again, due the the lack of documentation of the vmm ioctls.

@emaste interesting work from Mario

@emaste I recall @seanwbruno or Warner working on transparent QEMU emulation on the command line. With BIOS emulation, QEMU solves a lot of niche problems.