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

[Jason Wang <jasowang@redhat.com>]

On 2020/10/29 下午8:08, Stefan Hajnoczi wrote:
> 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


I'm not sure this can work:

1) Reading something that is opaque to userspace is probably a hint of 
bad uAPI design
2) Did qemu even try to migrate opaque blobs before? It's probably a bad 
design of migration protocol as well.

It looks to me have a migration driver in qemu that can clearly define 
each byte in the migration stream is a better approach.


>          * 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


It could be even more easier, e.g for the inflight indices, we can 
design (or forcing to use in order) virtqueue carefully then we don't 
need any auxiliary data structure.

Thanks


>      * 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
>