On Thu, Oct 29, 2020 at 1:03 PM Jason Wang <jasow...@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.055c3...@x1.home/t/ There is also a QEMU patch series: https://patchwork.kernel.org/project/qemu-devel/cover/1566845753-18993-1-git-send-email-kwankh...@nvidia.com/ Kirti is also on the CC list if you want to discuss specific questions. Stefan
