* Lan, Tianyu (tianyu.lan@xxxxxxxxx) 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.
OK, hmm - I can see that would work in some cases; but:
a) It wouldn't work if the guest was paused, the management can pause it before
starting migration or during migration - so you might need to hook the pause
as well; so that's a bit complicated.
b) How long does qemu wait for the guest to respond, and what does it do if
the guest doesn't respond ? How do we recover?
c) How much work does the guest need to do at this point?
d) It would be great if we could find a more generic way of telling the guest
it's about to migrate rather than via the PCI registers of one device; imagine
what happens if you have a few different devices using SR-IOV, we'd have to tell
them all with separate interrupts. Perhaps we could use a virtio channel or
an ACPI event or something?
> >>>> >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 and it's hard to modify
> bus level code. It also will block implementation on the Windows.
Well, there was agraf's trick, although that's a lot more complicated at the qemu
level, but it should work with no guest modifications. Michael's point about
dirty page tracking is neat, I think that simplifies it a bit if it can track dirty
pages.
Dave
> >Dave
> >
--
Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
--
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
