On Wed, Dec 2, 2015 at 6:08 AM, Lan, Tianyu <tianyu....@intel.com> wrote: > On 12/1/2015 11:02 PM, Michael S. Tsirkin wrote: >>> >>> But >>> it requires guest OS to do specific configurations inside and rely on >>> bonding driver which blocks it work on Windows. >>> From performance side, >>> putting VF and virtio NIC under bonded interface will affect their >>> performance even when not do migration. These factors block to use VF >>> NIC passthough in some user cases(Especially in the cloud) which require >>> migration. >> >> >> That's really up to guest. You don't need to do bonding, >> you can just move the IP and mac from userspace, that's >> possible on most OS-es. >> >> Or write something in guest kernel that is more lightweight if you are >> so inclined. What we are discussing here is the host-guest interface, >> not the in-guest interface. >> >>> Current solution we proposed changes NIC driver and Qemu. Guest Os >>> doesn't need to do special thing for migration. >>> It's easy to deploy >> >> >> >> Except of course these patches don't even work properly yet. >> >> And when they do, even minor changes in host side NIC hardware across >> migration will break guests in hard to predict ways. > > > Switching between PV and VF NIC will introduce network stop and the > latency of hotplug VF is measurable. For some user cases(cloud service > and OPNFV) which are sensitive to network stabilization and performance, > these are not friend and blocks SRIOV NIC usage in these case. We hope > to find a better way to make SRIOV NIC work in these cases and this is > worth to do since SRIOV NIC provides better network performance compared > with PV NIC. Current patches have some issues. I think we can find > solution for them andimprove them step by step.
I still believe the concepts being put into use here are deeply flawed. You are assuming you can somehow complete the migration while the device is active and I seriously doubt that is the case. You are going to cause data corruption or worse cause a kernel panic when you end up corrupting the guest memory. You have to halt the device at some point in order to complete the migration. Now I fully agree it is best to do this for as small a window as possible. I really think that your best approach would be embrace and extend the current solution that is making use of bonding. The first step being to make it so that you don't have to hot-plug the VF until just before you halt the guest instead of before you start he migration. Just doing that would yield a significant gain in terms of performance during the migration. In addition something like that should be able to be done without having to be overly invasive into the drivers. A few tweaks to the DMA API and you could probably have that resolved. As far as avoiding the hot-plug itself that would be better handled as a separate follow-up, and really belongs more to the PCI layer than the NIC device drivers. The device drivers should already have code for handling a suspend/resume due to a power cycle event. If you could make use of that then it is just a matter of implementing something in the hot-plug or PCIe drivers that would allow QEMU to signal when the device needs to go into D3 and when it can resume normal operation at D0. You could probably use the PCI Bus Master Enable bit as the test on if the device is ready for migration or not. If the bit is set you cannot migrate the VM, and if it is cleared than you are ready to migrate. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
