qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avihai Horon
Subject: Re: [PATCH 0/9] migration: Drop/unexport migration_is_device() and migration_is_active()
Date: Mon, 16 Dec 2024 16:45:31 +0200
User-agent: Mozilla Thunderbird


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]