qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC PATCH 0/5] Save state error handling (kill off no_


From: Alex Williamson
Subject: [Qemu-devel] Re: [RFC PATCH 0/5] Save state error handling (kill off no_migrate)
Date: Tue, 05 Oct 2010 20:29:37 -0600

On Tue, 2010-10-05 at 14:58 -0600, Alex Williamson wrote:
> On Tue, 2010-10-05 at 15:49 -0500, Anthony Liguori wrote:
> > On 10/05/2010 03:46 PM, Alex Williamson wrote:
> > > On Tue, 2010-10-05 at 15:41 -0500, Anthony Liguori wrote:
> > >    
> > >> On 10/05/2010 03:35 PM, Alex Williamson wrote:
> > >>      
> > >>> I was thinking of making KVM VMs with assigned PCI devices
> > >>> unsavable/unmigratable, but I wasn't thrilled with the
> > >>> no_migrate solutions.  The more generic solutions seems to be
> > >>> simply letting save handlers return an error if the device can't
> > >>> be migrated.  This is also much more generic than a one-way
> > >>> bit flip of the no_migrate flag.  For a vmsd based registration,
> > >>> the pre_save() routine seems to be the right place to allow
> > >>> devices to abort.  The series also carries the error back through
> > >>> all the vmstate callers.  If this looks good, I'll give it some
> > >>> more testing and submit as non-RFC.  Thanks,
> > >>>
> > >>>        
> > >> Doesn't this mean that we don't fail the migration until after
> > >> transferring all of the memory contents?
> > >>      
> > > That's the case with the current no_migrate implementation too, it
> > > doesn't get called until qemu_savevm_state_complete().  Thanks,
> > >    
> > 
> > Ouch, that's unfortunate but also should be easily fixable.
> > 
> > But making a save handler fail seems would make it impossible to get 
> > instant failure semantics.
> 
> True.  Ok, so maybe we do still need a separate no migrate registration.
> In any case, I think it's a good idea to allow the save routines to have
> a failure path, but I'll work on a way to disable migration that's not
> quite so coupled with the savevm entry (it seems silly for device
> assignment to register a savevm only for the purpose of then registering
> as non-migratable).  Thanks,

On second thought, I think we should take the same approach with the
live handlers.  We just need to make SaveSetParamsHandler return an int
and check it and the SaveLiveStateHandler return for < 0.  Then we have
a full spectrum of points at which a savevm handler can abort a
migration.  If that sounds reasonable, I'll send a new series tomorrow.
Thanks,

Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]