On Sun, Dec 27, 2015 at 7:20 PM, Dong, Eddie <eddie.dong@xxxxxxxxx> wrote: >> > >> > Even if the device driver doesn't support migration, you still want to >> > migrate VM? That maybe risk and we should add the "bad path" for the >> > driver at least. >> >> At a minimum we should have support for hot-plug if we are expecting to >> support migration. You would simply have to hot-plug the device before you >> start migration and then return it after. That is how the current bonding >> approach for this works if I am not mistaken. > > Hotplug is good to eliminate the device spefic state clone, but bonding approach is very network specific, it doesn’t work for other devices such as FPGA device, QaT devices & GPU devices, which we plan to support gradually :) Hotplug would be usable for that assuming the guest supports the optional "pause" implementation as called out in the PCI hotplug spec. With that the device can maintain state for some period of time after the hotplug remove event has occurred. The problem is that you have to get the device to quiesce at some point as you cannot complete the migration with the device still active. The way you were doing it was using the per-device configuration space mechanism. That doesn't scale when you have to implement it for each and every driver for each and every OS you have to support. Using the "pause" implementation for hot-plug would have a much greater likelihood of scaling as you could either take the fast path approach of "pausing" the device to resume it when migration has completed, or you could just remove the device and restart the driver on the other side if the pause support is not yet implemented. You would lose the state under such a migration but it is much more practical than having to implement a per device solution. - Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
