Re: Out-of-Process Device Emulation session at KVM Forum 2020

[Stefan Hajnoczi <stefanha@gmail.com>]

Here are notes from the session:

protocol stability:
    * vhost-user already exists for existing third-party applications
    * vfio-user is more general but will take more time to develop
    * libvfio-user can be provided to allow device implementations

management:
    * Should QEMU launch device emulation processes?
        * Nicer user experience
        * Technical blockers: forking, hotplug, security is hard once
QEMU has started running
        * Probably requires a new process model with a long-running
QEMU management process proxying QMP requests to the emulator process

migration:
    * dbus-vmstate
    * VFIO live migration ioctls
        * Source device can continue if migration fails
        * Opaque blobs are transferred to destination, destination can
fail migration if it decides the blobs are incompatible
        * How does the VMM share the migration data region with the
device emulation process?
            * The vfio-user protocol can trap or mmap
    * device versioning (like versioned machine types) needed to pin
the guest-visible device ABI
    * Felipe will investigate live migration

reconnection:
    * How to support reconnection?
        * QEMU has relatively little state of a vfio-user device
        * vhost-user has more state so it's a little easier to
reconnect or migrate
    * Build in reconnection and live migration from the start to avoid
difficulties in the future
    * Relationship between migration and reconnection?
        * VFIO has a mechanism for saving/loading device state
        * Lots of different reconnection cases that need to be thought through

security & sandboxing:
    * Goal: make it easy to lock down the process so developers don't
need to reinvent sandboxing
    * minijail
        * in-process
    * firecracker jailer
    * bubblewrap
        * launcher tool
    * systemd-run
        * launcher tool