On Sun, Feb 24, 2019 at 12:21:24PM -0500, Dave Voutila wrote: > I've been experimenting with implementing something like vmmci(4) for > Linux guests. It's started to prove useful to myself so maybe others > will benefit, even though there are currently some caveats[1]. > > https://github.com/voutilad/virtio_vmmci > > My primary use case is keeping some Linux guests constantly running in > the background under the vmm(4) hypervisor on my laptop that sees quite > a few suspend (zzz)/resume cycles throughout my day. > > It currently consists of 2 Linux kernel modules, one representing a > virtio_pci implementation handling the quirks[2] of how vmd(8) exposes > the vmm control device and the other module is the actual virtio driver > implementation. > > I've tested it with a stock Ubuntu 18.0.4 install as well as with a > newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and > work just fine using an OpenBSD snapshot from Monday 18 Feb as the host. > > It doesn't yet catch shutdown or restart events, but that's my next goal > since I'd like to make sure I get clean shutdowns via `vmctl stop`. > > -Dave > > [1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats > [2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking > [3]: https://github.com/voutilad/linux >
Looks like a good start! For what it's worth, we should probably allocate a real virtio device number from Redhat or whoever controls that. I have an old email in my inbox with a few contact names, but I never got around to following up. That would fix the problem of the "stolen" virtio ID. We chose to implement what looks like a PCI hostbridge but used a fake PCI VID/PID for this. The reason for doing it this way is that if you say you are a host bridge that is well-known, you have to implement all the bug-for-bug compatibility that comes with that. I'll take a look at the register read/write thing, I'm not sure I entirely understand the issue you saw. -ml
