From: Joao Martins <joao.m.martins@oracle.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>
Cc: "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"clg@redhat.com" <clg@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Peng, Chao P" <chao.p.peng@intel.com>
Subject: Re: [PATCH] vfio/migration: Fix return value of vfio_migration_realize()
Date: Thu, 15 Jun 2023 11:22:30 +0100 [thread overview]
Message-ID: <186c9e07-c1e6-74ae-0a4f-7d6bc0c8ceb6@oracle.com> (raw)
In-Reply-To: <SJ0PR11MB6744E8D7540A3B9E540A9F69925BA@SJ0PR11MB6744.namprd11.prod.outlook.com>
On 15/06/2023 10:19, Duan, Zhenzhong wrote:
>> -----Original Message-----
>> From: Joao Martins <joao.m.martins@oracle.com>
>> Sent: Thursday, June 15, 2023 4:54 PM
>> To: Duan, Zhenzhong <zhenzhong.duan@intel.com>
>> Cc: alex.williamson@redhat.com; clg@redhat.com; qemu-devel@nongnu.org;
>> Peng, Chao P <chao.p.peng@intel.com>
>> Subject: Re: [PATCH] vfio/migration: Fix return value of vfio_migration_realize()
>>
>>
>>
>> On 15/06/2023 09:18, Zhenzhong Duan wrote:
>>> We should print "Migration disabled" when migration is blocked in
>>> vfio_migration_realize().
>>>
>>> Fix it by reverting return value of migrate_add_blocker(), meanwhile
>>> error out directly once migrate_add_blocker() failed.
>>>
>>
>> It wasn't immediately obvious from commit message that this is mainly about
>> just printing an error message when blockers get added and that well
>> migrate_add_blocker() returns 0 on success and caller of
>> vfio_migration_realize expects the opposite when blockers are added.
>>
>> Perhaps better wording would be:
>>
>> migrate_add_blocker() returns 0 when successfully adding the migration
>> blocker. However, the caller of vfio_migration_realize() considers that
>> migration was blocked when the latter returned an error. Fix it by negating the
>> return value obtained by migrate_add_blocker(). What matters for migration
>> is that the blocker is added in core migration, so this cleans up usability such
>> that user sees "Migrate disabled" when any of the vfio migration blockers are
>> active.
>
> Great, I'll use your words.
>
>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>> ---
>>> hw/vfio/common.c | 4 ++--
>>> hw/vfio/migration.c | 6 +++---
>>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c index
>>> fa8fd949b1cf..8505385798f3 100644
>>> --- a/hw/vfio/common.c
>>> +++ b/hw/vfio/common.c
>>> @@ -399,7 +399,7 @@ int vfio_block_multiple_devices_migration(Error
>> **errp)
>>> multiple_devices_migration_blocker = NULL;
>>> }
>>>
>>> - return ret;
>>> + return !ret;
>>> }
>>>
>>> void vfio_unblock_multiple_devices_migration(void)
>>> @@ -444,7 +444,7 @@ int vfio_block_giommu_migration(Error **errp)
>>> giommu_migration_blocker = NULL;
>>> }
>>>
>>> - return ret;
>>> + return !ret;
>>> }
>>>
>>> void vfio_migration_finalize(void)
>>> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c index
>>> 6b58dddb8859..0146521d129a 100644
>>> --- a/hw/vfio/migration.c
>>> +++ b/hw/vfio/migration.c
>>> @@ -646,12 +646,12 @@ int vfio_migration_realize(VFIODevice *vbasedev,
>> Error **errp)
>>> }
>>>
>>> ret = vfio_block_multiple_devices_migration(errp);
>>> - if (ret) {
>>> + if (ret || (errp && *errp)) {
>>
>> Why do you need this extra clause?
>
> Now that error happens, no need to add other blockers which will fail for
> same reason.
>
But you don't need the (errp && *errp) for that as that's the whole point of
negating the result.
And if there's an error set it means migrate_add_blocker failed to add the
blocker (e.g. snapshotting IIUC), and you would be failing here unnecessarily?
Still it feels strange to use the error pointer to check for that, it's better
to return error appropriately.
>>
>>> return ret;
>>> }
>>>
>>> ret = vfio_block_giommu_migration(errp);
>>> - if (ret) {
>>> + if (ret || (errp && *errp)) {
>>
>> Same here?
>
> To avoid calling into trace_vfio_migration_probe() which hints vfio migration realize succeed.
>
That was clear, my question was more related to second clause you are adding..
> Thanks
> Zhenzhong
>
>>
>>> return ret;
>>> }
>>>
>>> @@ -667,7 +667,7 @@ add_blocker:
>>> error_free(vbasedev->migration_blocker);
>>> vbasedev->migration_blocker = NULL;
>>> }
>>> - return ret;
>>> + return !ret;
>>> }
>>>
>>> void vfio_migration_exit(VFIODevice *vbasedev)
next prev parent reply other threads:[~2023-06-15 10:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 8:18 [PATCH] vfio/migration: Fix return value of vfio_migration_realize() Zhenzhong Duan
2023-06-15 8:53 ` Joao Martins
2023-06-15 9:19 ` Duan, Zhenzhong
2023-06-15 10:22 ` Joao Martins [this message]
2023-06-16 2:42 ` Duan, Zhenzhong
2023-06-16 9:05 ` Joao Martins
2023-06-16 9:53 ` Duan, Zhenzhong
2023-06-16 10:12 ` Joao Martins
2023-06-16 14:04 ` Cédric Le Goater
2023-06-16 18:06 ` Joao Martins
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=186c9e07-c1e6-74ae-0a4f-7d6bc0c8ceb6@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=chao.p.peng@intel.com \
--cc=clg@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhenzhong.duan@intel.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).