>-----Original Message-----
>From: Joao Martins <joao.m.mart...@oracle.com>
>Sent: Monday, June 26, 2023 6:19 PM
>To: Avihai Horon <avih...@nvidia.com>; Duan, Zhenzhong
><zhenzhong.d...@intel.com>
>Cc: alex.william...@redhat.com; c...@redhat.com; Peng, Chao P
><chao.p.p...@intel.com>; qemu-devel@nongnu.org
>Subject: Re: [PATCH v3 3/3] vfio/migration: vfio/migration: Refactor and fix
>print of "Migration disabled"
>
>
>
>On 26/06/2023 10:34, Avihai Horon wrote:
>>
>> On 21/06/2023 11:02, Zhenzhong Duan wrote:
...
>>> -void vfio_migration_finalize(void)
>>> +bool vfio_block_giommu_migration(VFIODevice *vbasedev)
>>> {
>>> - if (!giommu_migration_blocker ||
>>> - vfio_viommu_preset()) {
>>> - return;
>>> - }
>>> -
>>> - migrate_del_blocker(giommu_migration_blocker);
>>> - error_free(giommu_migration_blocker);
>>> - giommu_migration_blocker = NULL;
>>> + return vbasedev->group->container->space->as !=
>>> +&address_space_memory;
>>> }
>>
>> I guess vfio_block_giommu_migration can be moved to migration.c and
>made static?
>> Although Joao's vIOMMU series will probably change that back later in some
>way.
>>
>I guess it makes sense -- the thing that was tieing him was the global
>migration
>blocker, which is now consolidated into the main migration blocker.
>
>My vIOMMU series will relax this condition yes (still same per-device scope).
>And I will need to check the maximum IOVA in the vIOMMU. But it's new code
>I can adjust and Zhenzhong shouldn't worry about the vIOMMU future stuff
A bit confused, you agreed to move vfio_block_giommu_migration into migration.c
>but I don't expect to influence location, say if it gets moved into migration.c
and final decision is no move for influencing location reason? Do I
misunderstand?
Thanks
Zhenzhong
