[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Gleb Natapov <gleb@redhat.com>]

On Mon, Nov 23, 2009 at 03:09:35PM +0100, Juan Quintela wrote:
> Gleb Natapov <gleb@redhat.com> wrote:
> > On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
> >> Gleb Natapov <gleb@redhat.com> wrote:
> >> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
> 
> > Yes, I proposed to send device state in multiple formats specifically to
> > prevent negotiation step, but may be proper negotiation is not so
> > bad/complex after all.
> 
> Advantages of proper negotation is that target can told you "no".  It
> does'nt matter the number of formats that you send, if the target don't
> understand them, it is not going to work.
> 
The only difference is when it will be known that migration is not
possible: before event attempting it or during migration.

> >> My problem implementing optional features/sections/... is not the
> >> savevm/VMState bits.  At the end, implementing that is easy.  What is
> >> more dificult is once that a device have 5 features, what are the valid
> >> combinations.  i.e. if you have pci and msix features, msix requires
> >> pci.  In this case, the dependency is trivial, but in others that
> >> hasen't to be so obvious.
> > It doesn't matter what device support and how it is configured. This can
> > be handled by each device separately. i.e if destination detects that
> > source had MSIX enabled for the device but destination hasn't it will
> > signal an error.
> 
> And guess what, with current code migration is going to "suceed" on the
> source host and fail on the target host.
Then current code is buggy. It should be possible to abort migration in
the middle if device can't understand the data it received.

--
			Gleb.