Alex Williamson <alex.williamson@xxxxxxxxxx> 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
>
Reviewed-by: Juan Quintela <quintela@xxxxxxxxxx>
Just to address some of mst concerns:
- no_migrate was wrong from the beggining. We have enough setup to
disable tihngs.
- I did save handlers that didn't return any error because they dind't
have it when I started, it would have been way better if I had done it
the other way around. I was going to need this change done _anyways_,
didn't start for there because there were other things to fix.
- we really need to be able to return errors in save paths:
* ihvm device, it can migrate some times, and no others (we can
discuss the details)
* device assignment: we can't migrate, and we need a way to say so.
* if we want reliable migration & machine definitions, we are going to
have to implement device versions at some point. This clearly
requires failure of save migration (i.e. we ask to save a device
with version n-1 (or without some subsection) and it finds that this
would breaks.
So I woh
Later, Juan.
--
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
