Re: [PATCH RFC] vfio: Revise and update the migration uAPI description

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jan 26, 2022 at 01:49:09AM +0000, Tian, Kevin wrote:

> > As STOP_PRI can be defined as halting any new PRIs and always return
> > immediately.
> 
> The problem is that on such devices PRIs are continuously triggered
> when the driver tries to drain the in-fly requests to enter STOP_P2P
> or STOP_COPY. If we simply halt any new PRIs in STOP_PRI, it
> essentially implies no migration support for such device.
 
So what can this HW even do? It can't immediately stop and disable its
queues?

Are you sure it can support migration?
 
> > STOP_P2P can hang if PRI's are open
> 
> In earlier discussions we agreed on a timeout mechanism to avoid such
> hang issue.

It is very ugly, ideally I'd prefer the userspace to handle the
timeout policy..

> > with the base feature set anyhow, as they can not support a RUNNING ->
> > STOP_COPY transition without, minimally, completing all the open
> > vPRIs. As VMMs implementing the base protocol should stop the vCPU and
> > then move the device to STOP_COPY, it is inherently incompatible with
> > what you are proposing.
> 
> My understanding is that STOP_P2P is entered before stopping vCPU.
> If that state can be extended for STOP_DMA, then it's compatible.

Well, it hasn't been coded yet, but this isn't strictly required to
achieve its purpose..

Jason