>-----Original Message----- >From: Joao Martins <joao.m.mart...@oracle.com> >Subject: Re: [PATCH rfcv2 18/18] intel_iommu: Block migration if cap is >updated > >On 27/02/2024 02:41, Duan, Zhenzhong wrote: >> >> >>> -----Original Message----- >>> From: Joao Martins <joao.m.mart...@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.d...@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?
If qemu starts with cold plugged vfio device, that vfio device may update cap/ecap. Even if that vfio device is unplugged at runtime, the changed cap/ecap is kept. In this case source and dest will have incompatible cap/ecap config. So I block migration if there is cap/ecap update on source side. This patch is to deal with the case that there is cold plugged vfio device which is unplugged at runtime and then migration happen. Thanks Zhenzhong
