qemu-devel
[Top][All Lists]
Advanced

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

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


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 0/6] Save state error handling (kill off no_migrate)
Date: Tue, 16 Nov 2010 11:23:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Alex Williamson <address@hidden> 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 <address@hidden>

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.



reply via email to

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