On Thu, Dec 10, 2015 at 10:38:32PM +0800, Lan, Tianyu wrote: > > > On 12/10/2015 7:41 PM, Dr. David Alan Gilbert wrote: > >>Ideally, it is able to leave guest driver unmodified but it requires the > >>>hypervisor or qemu to aware the device which means we may need a driver in > >>>hypervisor or qemu to handle the device on behalf of guest driver. > >Can you answer the question of when do you use your code - > > at the start of migration or > > just before the end? > > Just before stopping VCPU in this version and inject VF mailbox irq to > notify the driver if the irq handler is installed. > Qemu side also will check this via the faked PCI migration capability > and driver will set the status during device open() or resume() callback.
Right, this is the "good path" optimization. Whether this buys anything as compared to just sending reset to the device when VCPU is stopped needs to be measured. In any case, we probably do need a way to interrupt driver on destination to make it reconfigure the device - otherwise it might take seconds for it to notice. And a way to make sure driver can handle this surprise reset so we can block migration if it can't. > > > >>>> >It would be great if we could avoid changing the guest; but at least > >>>> >your guest > >>>> >driver changes don't actually seem to be that hardware specific; could > >>>> >your > >>>> >changes actually be moved to generic PCI level so they could be made > >>>> >to work for lots of drivers? > >>> > >>>It is impossible to use one common solution for all devices unless the PCIE > >>>spec documents it clearly and i think one day it will be there. But before > >>>that, we need some workarounds on guest driver to make it work even it > >>>looks > >>>ugly. > > Yes, so far there is not hardware migration support VT-D supports setting dirty bit in the PTE in hardware. > and it's hard to modify > bus level code. Why is it hard? > It also will block implementation on the Windows. Implementation of what? We are discussing motivation here, not implementation. E.g. windows drivers typically support surprise removal, should you use that, you get some working code for free. Just stop worrying about it. Make it work, worry about closed source software later. > >Dave > > -- 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
