All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, cam@cs.ualberta.ca, kvm@vger.kernel.org
Subject: Re: [PATCH 0/6] Save state error handling (kill off no_migrate)
Date: Tue, 16 Nov 2010 11:23:43 +0100	[thread overview]
Message-ID: <m3eiaqrd6u.fsf@trasno.mitica> (raw)
In-Reply-To: <20101006204546.32127.70109.stgit@s20.home> (Alex Williamson's message of "Wed, 06 Oct 2010 14:58:57 -0600")

Alex Williamson <alex.williamson@redhat.com> 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@redhat.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Juan Quintela <quintela@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: cam@cs.ualberta.ca, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [PATCH 0/6] Save state error handling (kill off no_migrate)
Date: Tue, 16 Nov 2010 11:23:43 +0100	[thread overview]
Message-ID: <m3eiaqrd6u.fsf@trasno.mitica> (raw)
In-Reply-To: <20101006204546.32127.70109.stgit@s20.home> (Alex Williamson's message of "Wed, 06 Oct 2010 14:58:57 -0600")

Alex Williamson <alex.williamson@redhat.com> 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@redhat.com>

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.

  parent reply	other threads:[~2010-11-16 10:23 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 20:58 [PATCH 0/6] Save state error handling (kill off no_migrate) Alex Williamson
2010-10-06 20:58 ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 1/6] savevm: Allow SaveStateHandler() to return error Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 2/6] savevm: Allow vmsd->pre_save " Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 3/6] pci: Allow pci_device_save() " Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 4/6] virtio: Allow virtio_save() errors Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 5/6] savevm: Allow set_params and save_live_state to error Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-06 20:59 ` [PATCH 6/6] savevm: Remove register_device_unmigratable() Alex Williamson
2010-10-06 20:59   ` [Qemu-devel] " Alex Williamson
2010-10-07 16:55 ` [PATCH 0/6] Save state error handling (kill off no_migrate) Alex Williamson
2010-10-07 16:55   ` [Qemu-devel] " Alex Williamson
2010-11-08 11:40 ` Michael S. Tsirkin
2010-11-08 11:40   ` [Qemu-devel] " Michael S. Tsirkin
2010-11-08 14:59   ` Alex Williamson
2010-11-08 14:59     ` [Qemu-devel] " Alex Williamson
2010-11-08 16:54     ` Michael S. Tsirkin
2010-11-08 16:54       ` [Qemu-devel] " Michael S. Tsirkin
2010-11-08 17:20       ` Alex Williamson
2010-11-08 17:20         ` [Qemu-devel] " Alex Williamson
2010-11-08 20:59         ` Michael S. Tsirkin
2010-11-08 20:59           ` [Qemu-devel] " Michael S. Tsirkin
2010-11-08 21:23           ` Alex Williamson
2010-11-08 21:23             ` [Qemu-devel] " Alex Williamson
2010-11-09 12:00             ` Michael S. Tsirkin
2010-11-09 12:00               ` [Qemu-devel] " Michael S. Tsirkin
2010-11-09 14:58               ` Alex Williamson
2010-11-09 14:58                 ` [Qemu-devel] " Alex Williamson
2010-11-09 15:07                 ` Michael S. Tsirkin
2010-11-09 15:07                   ` [Qemu-devel] " Michael S. Tsirkin
2010-11-09 15:34                   ` Alex Williamson
2010-11-09 15:34                     ` [Qemu-devel] " Alex Williamson
2010-11-09 15:42                     ` Michael S. Tsirkin
2010-11-09 15:42                       ` [Qemu-devel] " Michael S. Tsirkin
2010-11-09 15:47                       ` Alex Williamson
2010-11-09 15:47                         ` [Qemu-devel] " Alex Williamson
2010-11-09 16:15                         ` Michael S. Tsirkin
2010-11-09 16:15                           ` [Qemu-devel] " Michael S. Tsirkin
2010-11-09 16:30                           ` Alex Williamson
2010-11-09 16:30                             ` [Qemu-devel] " Alex Williamson
2010-11-09 16:49                             ` Michael S. Tsirkin
2010-11-09 16:49                               ` [Qemu-devel] " Michael S. Tsirkin
2010-11-09 17:44                               ` Alex Williamson
2010-11-09 17:44                                 ` [Qemu-devel] " Alex Williamson
2010-11-09 19:35                                 ` Alex Williamson
2010-11-09 19:35                                   ` [Qemu-devel] " Alex Williamson
2010-11-16 10:23 ` Juan Quintela [this message]
2010-11-16 10:23   ` Juan Quintela

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3eiaqrd6u.fsf@trasno.mitica \
    --to=quintela@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=cam@cs.ualberta.ca \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.