From: Peter Xu <peterx@redhat.com>
To: Avihai Horon <avihaih@nvidia.com>
Cc: qemu-devel@nongnu.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Juan Quintela" <quintela@redhat.com>,
"Leonardo Bras" <leobras@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Maor Gottlieb" <maorg@nvidia.com>,
"Kirti Wankhede" <kwankhede@nvidia.com>,
"Tarun Gupta" <targupta@nvidia.com>,
"Joao Martins" <joao.m.martins@oracle.com>
Subject: Re: [PATCH v2 3/7] migration: Enable precopy initial data capability
Date: Wed, 17 May 2023 12:07:52 -0400 [thread overview]
Message-ID: <ZGT72DLNTevauf9N@x1n> (raw)
In-Reply-To: <20230517155219.10691-4-avihaih@nvidia.com>
On Wed, May 17, 2023 at 06:52:15PM +0300, Avihai Horon wrote:
> Now that precopy initial data logic has been implemented, enable the
> capability.
>
> Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> Reviewed-by: Juan Quintela <quintela@redhat.com>
> ---
> migration/options.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/migration/options.c b/migration/options.c
> index 0a31921a7a..3449ce4f14 100644
> --- a/migration/options.c
> +++ b/migration/options.c
> @@ -561,10 +561,6 @@ bool migrate_caps_check(bool *old_caps, bool *new_caps, Error **errp)
> "capability 'return-path'");
> return false;
> }
> -
> - /* Disable this capability until it's implemented */
> - error_setg(errp, "'precopy-initial-data' is not implemented yet");
> - return false;
> }
I'm always confused why we need this and not having this squashed into
patch 1 (or say, never have these lines).
The only thing it matters is when someone backports patch 1 but not
backport the rest of the patches. But that's really, really weird already
as a backporter doing that, and I doubt its happening.
Neither should we merge patch 1 without merging follow up patches to
master, as we should just always merge the whole feature or just keep
reworking on the list.
I'd like to know if I missed something else..
PS: sorry to be late on replying to your email for previous version due to
travelling last week, I'll reply to your series instead. Actually I was
just writting up the reply to your previous version when receiving this
one. :)
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2023-05-17 16:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 15:52 [PATCH v2 0/7] migration: Add precopy initial data capability and VFIO precopy support Avihai Horon
2023-05-17 15:52 ` [PATCH v2 1/7] migration: Add precopy initial data capability Avihai Horon
2023-05-17 15:52 ` [PATCH v2 2/7] migration: Implement precopy initial data logic Avihai Horon
2023-05-17 16:39 ` Peter Xu
2023-05-18 7:45 ` Avihai Horon
2023-05-17 15:52 ` [PATCH v2 3/7] migration: Enable precopy initial data capability Avihai Horon
2023-05-17 16:07 ` Peter Xu [this message]
2023-05-18 7:26 ` Avihai Horon
2023-05-18 13:42 ` Peter Xu
2023-05-18 16:51 ` Avihai Horon
2023-05-17 15:52 ` [PATCH v2 4/7] tests: Add migration precopy initial data capability test Avihai Horon
2023-05-17 16:40 ` Peter Xu
2023-05-17 15:52 ` [PATCH v2 5/7] vfio/migration: Refactor vfio_save_block() to return saved data size Avihai Horon
2023-05-17 15:52 ` [PATCH v2 6/7] vfio/migration: Add VFIO migration pre-copy support Avihai Horon
2023-05-17 15:52 ` [PATCH v2 7/7] vfio/migration: Add support for precopy initial data capability Avihai Horon
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=ZGT72DLNTevauf9N@x1n \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=kwankhede@nvidia.com \
--cc=leobras@redhat.com \
--cc=lvivier@redhat.com \
--cc=maorg@nvidia.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=targupta@nvidia.com \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=yishaih@nvidia.com \
/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.