[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH rfcv2 18/18] intel_iommu: Block migration if cap is updated
|
From: |
Joao Martins |
|
Subject: |
Re: [PATCH rfcv2 18/18] intel_iommu: Block migration if cap is updated |
|
Date: |
Tue, 27 Feb 2024 11:08:23 +0000 |
On 27/02/2024 02:41, Duan, Zhenzhong wrote:
>
>
>> -----Original Message-----
>> From: Joao Martins <joao.m.martins@oracle.com>
>> Subject: Re: [PATCH rfcv2 18/18] intel_iommu: Block migration if cap is
>> updated
>>
>> On 01/02/2024 07:28, Zhenzhong Duan wrote:
>>> When there is VFIO device and vIOMMU cap/ecap is updated based on
>> host
>>> IOMMU cap/ecap, migration should be blocked.
>>>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>
>> Is this really needed considering migration with vIOMMU is already blocked
>> anyways?
>
> VFIO device can be hot unplugged, then blocker due to vIOMMU is removed,
> but we still need a blocker for cap/ecap update.
>
Right which then the blocker gets re-added after you add one VFIO device. The
commit message refers xplicitly VFIO device, why would you care about blocking
migration on vIOMMU without vfio devices present? Maybe there's another reason
but that the commit messages doesn't cover? like guest MGAW being bigger than
host MGAW or something like that?
Joao
[PATCH rfcv2 15/18] backends/iommufd: Introduce helper function iommufd_device_get_info(), Zhenzhong Duan, 2024/02/01
[PATCH rfcv2 17/18] intel_iommu: Use mgaw instead of s->aw_bits, Zhenzhong Duan, 2024/02/01
[PATCH rfcv2 16/18] intel_iommu: Implement check and sync mechanism in iommufd mode, Zhenzhong Duan, 2024/02/01