[Qemu-devel] Re: [PATCH 0/6] Save state error handling (kill off no_migrate)

[Alex Williamson <alex.williamson@redhat.com>]

On Mon, 2010-11-08 at 13:40 +0200, Michael S. Tsirkin wrote:
> On Wed, Oct 06, 2010 at 02:58:57PM -0600, Alex Williamson wrote:
> > Our code paths for saving or migrating a VM are full of functions that
> > return void, leaving no opportunity for a device to cancel a migration,
> > either from error or incompatibility.  The ivshmem driver attempted to
> > solve this with a no_migrate flag on the save state entry.  I think the
> > more generic and flexible way to solve this is to allow driver save
> > functions to fail.  This series implements that and converts ivshmem
> > to uses a set_params function to NAK migration much earlier in the
> > processes.  This touches a lot of files, but bulk of those changes are
> > simply s/void/int/ and tacking a "return 0" to the end of functions.
> > Thanks,
> > 
> > Alex
> 
> Well error handling is always tricky: it seems easier to
> require save handlers to never fail.

Sure it's easier, but does that make it robust?

> So there's a bunch of code here but what exactly is the benefit?
> Since save handlers have no idea what does the remote do,
> what is the compatibility you mention?

There are two users I currently have in mind.  ivshmem currently makes
use of the register_device_unmigratable() because it makes use of host
specific resources and connections (aiui).  This sets the no_migrate
flag, which is not dynamic and a bit of a band-aide.  The other is
device assignment, which needs a way to NAK a migration since physical
devices are never migratable.  I imagine we could at some point have
devices with state tied to other features that can't always be detached
from the host, this tries to provide the infrastructure for that to
happen.

Alex