Re: virtual machine strategy soptions

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Greg Troxel <gdt%lexort.com@localhost> wrote:
>Robert Swindells <rjs%fdy2.co.uk@localhost> writes:
>>
>> Aryabhata <bsdhexa%gmail.com@localhost> wrote:
>>> Is there any serious momentum behind getting OpenBSD's vmm or FreeBSD's
>>> bhyve working seamlessly as the frontend for NVMM? I'd much rather
>>> migrate to a clean, human-maintained codebase than deal with the fallout
>>> of whatever QEMU is about to merge into their tree.
>>
>> The interrupt handling emulation in qemu doesn't work very well when
>> trying to boot Linux in a VM, is bhyve better at this?
>>
>> There could also be a future project to add support for virtual
>> interrupts (AVIC and the Intel equivalent) to nvmm(4), then use that in
>> the userspace client, this might be easier to do in a smaller codebase
>> like bhyve.
>
> I have been seeing mentions of FreeBSD bhyve for a long time and not
> been clear on it.
> 
> I wonder if anyone can explain
>
>   Does bhyve use qemu for full virtualization?  Something else?  Is
>   there a PV method?   Can you e.g. boot Windows under bhyve?

On FreeBSD, bhyve is just the userland application that provides some of
the equivalent functionality to qemu, it provides full hardware
virtualization by controlling their kernel equivalent to nvmm(4) which
is called 'vmm'.

It doesn't provide software emulation of individual instructions but
does have virtual I/O features that I think are effectively PV.

There is also a userland shim called libvmmapi equivalent to our libnvmm
that lives underneath bhyve.

>  Is OpenBSD vmm related to NetBSD's nvmm?  I am guessing not, and am
>  probably remembering something about nvmm in DragonFly.   It looks
>  like OpenBSD's support is restricted and probably doesn't include full
>  HVM operation and thus doesn't have qemu.

I think that OpenBSD calls both their userland and kernel parts vmm,

Their userland looks to be able to start up a HVM from a disk image file
so doesn't need qemu.


You can build qemu to be the userland controller for hardware
virtualization using kvm on Linux, Hyper-V and our nvmm(4).

When a HVM hits a condition that it can't handle it exits back to
whichever host application is being used and that fixes up whatever is
needed then resumes the VM. These fixups can be for things like
emulation of the interrupt controller.

Alternatively, qemu can emulate a defined system completely in software.