Re: [PATCH 2/2] vfio/migration: Parallelize device state transitions

[Peter Xu <peterx@redhat.com>]

On Thu, Jul 02, 2026 at 08:36:32PM +0200, Maciej S. Szmigiero wrote:
> I looked more deeply into this and even prototyped a similar new design.

Sorry for a late response; off work most of last week.

> 
> However, in the end I think that running VFIO state transitions in
> parallel with other non-VFIO cb() handlers just isn't safe.
> 
> For example, on the migration source, the second transition is
> PRE_COPY_P2P -> STOP_COPY.
> PRE_COPY_P2P is the last state during migration that still allows the
> device to accept DMA and similar interactions, while STOP_COPY is
> already the "quiescent" state.
> 
> So if a VFIO has already reached STOP_COPY but a non-VFIO device
> callback still hasn't finished, then any DMA/MMIO/P2P transaction from
> that "unfinished" device to the VFIO device would now hit a VFIO device
> that no longer can accept such transactions.
> This may result in hard-to-debug memory corruption during live migration.

Do you have any solid example of this problem?

AFAIU, P2P in VFIO state's term only means P2P DMAs _between_ host VFIO
devices, nothing to do with emulated.

I am not aware of any P2P that can be initiated from emulated devices, even
if it exists, it is only P2P from guest perspective not host: it will
become host operations finally from processor side.  I really don't think
it's a concern.

My limited understanding of VFIO's P2P state is: when switching to P2P
state, the VFIO device can still accept P2P DMA from other devices, but
never initiating P2P DMAs, and the latter sentence is critical, it means
the real quiecent state of the whole system happens after the last VFIO
device switching to P2P state: then it means none of the VFIO devices can
initiate P2P DMA anymore, whole system is quiesced.  That happens earlier
than reaching any of the cb()s here, because VFIO's prepare_cb() does that
P2P state switch.

Thanks,

-- 
Peter Xu