On Mon, Nov 02, 2020 at 05:34:50AM -0500, Michael S. Tsirkin wrote: > On Mon, Nov 02, 2020 at 10:27:54AM +0000, Stefan Hajnoczi wrote: > > On Mon, Nov 02, 2020 at 11:00:12AM +0800, Jason Wang wrote: > > > > > > On 2020/10/30 下午7:13, Stefan Hajnoczi wrote: > > > > > I still don't get why it must be opaque. > > > > If the device state format needs to be in the VMM then each device > > > > needs explicit enablement in each VMM (QEMU, cloud-hypervisor, etc). > > > > > > > > Let's invert the question: why does the VMM need to understand the > > > > device state of a_passthrough_ device? > > > > > > > > > It's not a 100% passthrough device if you want to support live migration. > > > E.g the device state save and restore is not under the control of drivers > > > in > > > the guest. > > > > VFIO devices are already not pure passthrough (even without mdev) since > > the PCI bus is emulated and device-specific quirks may be implemented. > > So since it's not a pure passthrough anyway, let's try to > introduce some standards even if we can not always enforce > them.
Yes, I agree. I've sent a document called "VFIO Migration" in a separate email thread that defines how to orchestrate migration with versioning. Maybe we can discuss the details there and figure out which guidelines and device state representations to standardize. Stefan
signature.asc
Description: PGP signature
