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.