From: Juan Quintela <quintela@redhat.com>
To: Tejus GK <tejus.gk@nutanix.com>
Cc: qemu-devel@nongnu.org, peterx@redhat.com, leobras@redhat.com
Subject: Re: [PATCH v5 2/2] migration: Update error description outside migration.c
Date: Wed, 04 Oct 2023 10:23:26 +0200 [thread overview]
Message-ID: <871qea6bk1.fsf@secure.mitica> (raw)
In-Reply-To: <c281b1e9-a027-4871-a1d5-7fc10f4ba1ed@nutanix.com> (Tejus GK's message of "Wed, 4 Oct 2023 09:58:59 +0530")
Tejus GK <tejus.gk@nutanix.com> wrote:
> On 03/10/23 6:14 pm, Juan Quintela wrote:
>> Tejus GK <tejus.gk@nutanix.com> wrote:
>>> A few code paths exist in the source code,where a migration is
>>> marked as failed via MIGRATION_STATUS_FAILED, but the failure happens
>>> outside of migration.c
>>>
>>> In such cases, an error_report() call is made, however the current
>>> MigrationState is never updated with the error description, and hence
>>> clients like libvirt never know the actual reason for the failure.
>>>
>>> This patch covers such cases outside of migration.c and updates the
>>> error description at the appropriate places.
>>>
>>> Acked-by: Peter Xu <peterx@redhat.com>
>>> Signed-off-by: Tejus GK <tejus.gk@nutanix.com>
>> Reviewed-by: Juan Quintela <quintela@redhat.com>
>> Queued.
> Thanks, will be sending out a patch with the "Reviewed by" trailer added.
Send the other one. This one is already queued.
I think that the error_report() thing, you need to review more things
than the one in this patch.
>>
>>> return ret;
>>> }
>>> }
>>> @@ -389,8 +390,8 @@ int vmstate_save_state_v(QEMUFile *f, const VMStateDescription *vmsd,
>>> vmdesc_loop);
>>> }
>>> if (ret) {
>>> - error_report("Save of field %s/%s failed",
>>> - vmsd->name, field->name);
>>> + error_setg(errp, "Save of field %s/%s failed",
>>> + vmsd->name, field->name);
>> Same here.
> You're right, I'm only setting it here and reporting it eventually in
> savevm.c. The trivial solution for this would have been directly doing
> a migrate_set_error() here, but that ended up breaking the build for
> the unit test test-vmstate.c
What was the error? Because the problem could be on the test.
>>
>>> if (vmsd->post_save) {
>>> vmsd->post_save(opaque);
>>> }
>> So, I am wondering if it could be better to just report the error in
>> a
>> single place for migration, and set it whenever we need it?
> Yes, that would be very convenient, for all the errors to be reported
> in lets say migration.c. Though that'd also require all the subsystems
> under migration.c to properly propagate the errors.
Yeap, it requires auditing all the entry points, but will make easier to
know when we just need to set the error, the system will do the rest.
Thanks, Juan.
next prev parent reply other threads:[~2023-10-04 8:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 6:55 [PATCH v5 0/2] migration: Update error description outside migration.c Tejus GK
2023-10-03 6:55 ` [PATCH v5 1/2] migration/vmstate: Introduce vmstate_save_state_with_err Tejus GK
2023-10-03 12:39 ` Juan Quintela
2023-10-03 6:55 ` [PATCH v5 2/2] migration: Update error description outside migration.c Tejus GK
2023-10-03 12:44 ` Juan Quintela
2023-10-04 4:28 ` Tejus GK
2023-10-04 8:23 ` Juan Quintela [this message]
2023-10-04 12:15 ` Tejus GK
2023-10-04 12:43 ` Juan Quintela
2023-10-04 13:37 ` 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=871qea6bk1.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=leobras@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tejus.gk@nutanix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).