From: Peter Xu <peterx@redhat.com>
To: Roman Khapov <rkhapov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, farosas@suse.de, eblake@redhat.com,
armbru@redhat.com, yc-core@yandex-team.ru
Subject: Re: [PATCH v2 1/2] qapi/migration.json: add reason to MIGRATION event
Date: Thu, 22 Feb 2024 17:22:40 +0800 [thread overview]
Message-ID: <ZdcSYEtQe8M69Uza@x1n> (raw)
In-Reply-To: <a804edf0-67d4-4752-b79f-c3e1ef3d72ff@yandex-team.ru>
On Wed, Feb 21, 2024 at 06:47:47PM +0500, Roman Khapov wrote:
> If I understood you right, you suggest to improve migrate_generate_event to
> accept MigrationState* instead of int* state (which is pointing to field
> MigrationState.state in all usages), and get error reason from
> MigrationState.error, if the new state is MIGRATION_STATE_FAILED, is it?
migrate_generate_event() is a migration internal function, it can directly
reference s->error with error_mutex held.
>
> That sounds reasonable, thanks!
>
> But I'm not sure if I got the idea of changing migrate_set_error correctly,
> can you explain in more details, please?
I fat-fingered.. sorry. I wanted to say migrate_set_state() below, and I
think migrate_set_state() can be kept untouched.
But please consider the other reviewer's comment first: if query-migrate
(or HMP "info migrate") works for you, then this interface is not needed.
>
> On 2/20/24 10:39, Peter Xu wrote:
> > On Thu, Feb 15, 2024 at 05:27:58PM +0500, Roman Khapov wrote:
> > > migrate_set_state(&mis->state, MIGRATION_STATUS_COLO,
> > > - MIGRATION_STATUS_COMPLETED);
> > > + MIGRATION_STATUS_COMPLETED, NULL);
> > Instead of enforcing migrate_set_error() to always pass an error, maybe we
> > can allow migrate_generate_event() to fetch s->error in FAILED state, if
> > that hint ever existed?
> >
> --
> Best regards,
> Roman Khapov
>
--
Peter Xu
next prev parent reply other threads:[~2024-02-22 9:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 12:27 [PATCH v2 0/2] Field 'reason' for MIGRATION event Roman Khapov
2024-02-15 12:27 ` [PATCH v2 1/2] qapi/migration.json: add reason to " Roman Khapov
2024-02-16 6:17 ` Markus Armbruster
2024-02-18 14:32 ` Roman Khapov
2024-02-19 6:35 ` Markus Armbruster
2024-02-21 13:36 ` Roman Khapov
2024-02-20 5:39 ` Peter Xu
2024-02-21 13:47 ` Roman Khapov
2024-02-22 9:22 ` Peter Xu [this message]
2024-02-15 12:27 ` [PATCH v2 2/2] migration: add error reason for failed MIGRATION events Roman Khapov
2024-02-21 14:45 ` [PATCH v2 0/2] Field 'reason' for MIGRATION event Fabiano Rosas
2024-02-22 7:01 ` Markus Armbruster
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=ZdcSYEtQe8M69Uza@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=rkhapov@yandex-team.ru \
--cc=yc-core@yandex-team.ru \
/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.