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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Oct 29, 2020 at 1:03 PM Jason Wang <jasowang@redhat.com> wrote:
> 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.

Here is the kernel patch series if you want to review it:
https://lore.kernel.org/kvm/20191203110412.055c38df@x1.home/t/

There is also a QEMU patch series:
https://patchwork.kernel.org/project/qemu-devel/cover/1566845753-18993-1-git-send-email-kwankhede@nvidia.com/

Kirti is also on the CC list if you want to discuss specific questions.

Stefan