Re: [PATCH 0/9] migration: Drop/unexport migration_is_device() and migration_is_active()

[Avihai Horon]

On 16/12/2024 14:00, Joao Martins wrote:
> External email: Use caution opening links or attachments
>
>
> On 16/12/2024 09:46, Avihai Horon wrote:
> > Hello,
> >
> > This follows up on Peter's series [1] to simplify migration status API
> > to a single migration_is_running() function.
> >
> > Peter's series tried to drop migration_is_device() and
> > migration_is_active(), however VFIO used them to check if dirty page
> > tracking has been started in order to avoid errors in log sync, so they
> > couldn't simply be dropped without some preliminary cleanups.
> >
> > This series handles these preliminary cleanups and eventually drops
> > migration_is_device() and unexports migration_is_active().
> >
> > The series has been migration tested with the following:
> > - VFIO device dirty tracking.
> > - Legacy VFIO iommu dirty tracking.
> > - vIOMMU + Legacy VFIO iommu dirty tracking (migration with vIOMMU is
> >    currently blocked, so I used a patched QEMU to allow it).
> vIOMMU on IOMMU HW doesn't suffer from the same problems of VF dirty tracking
> where there's a aggregate limit into how much VFs can track in terms of IOVA
> space. So we can lift some of those restrictions for IOMMU even right now
> provided we implement the last remaining pre-requisite.

That would be helpful if there is a user who needs migration (with iommu 
DPT) + vIOMMU support right now. Otherwise, we don't have to rush and we 
can do it along with the optimizations or whatever we see fit.
I only needed migration + vIOMMU to test the vIOMMU dma unmap flow.

> I also have a much
> smaller series for that sort of unblockage that I can give you a pointer.

Yes, if you have it at hand, that could be useful for testing next versions.

> Though, eventually the optimizations we will do for VF dirty tracking for vIOMMU
> will apply to IOMMU HW too just so we minimize the amount of calls to get dirty
> bits.
>
> > I didn't test it with iommu DPT as I don't have access to such HW.
> > Cedric, I remember you said that you have such HW, it would be very
> > helpful if you could test it.
> I am starting to prep the unblocking vIOMMU for Qemu 10, so I can validate if
> this series works as well -- but from what I have looked so far it should be all
> OK.

Thanks, that wouldn't hurt :)

> If it helps I have some pending series that lets you test emulated x86 IOMMU
> DPT support (either on intel-iommu or amd-iommu) that can help you when you
> don't have the hardware to test.

That would be great, I didn't know such thing existed.

Thanks!

> Regarding this series, since you are looking at the the dirty tracking 'status'
> I'll comment here too as one of your original patches introduced it as it's
> related to the use of migration_is_running(). And since you're looking at this
> exact part of the code, might as well cover that too.