|
From: | Jason Wang |
Subject: | Re: Out-of-Process Device Emulation session at KVM Forum 2020 |
Date: | Thu, 29 Oct 2020 21:02:05 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |