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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jan 26, 2022 at 08:14:47AM -0400, Jason Gunthorpe wrote:
> > > 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..

Sorry, this isn't quite clear

The base v2 protocol specified RUNNING -> STOP(_COPY) as the only FSM
arc, and due to the definition of STOP this must be done with the vCPU
suspended.

So, this vPRI you are talking about simply cannot implement this, and
is incompatible with the base protocol that requires it.

Thus we have a device in this mode unable to do certain FSM
transitions, like RUNNING -> STOP and should block them.

On the other hand, the P2P stuff is deliberately compatible and due to
this there will be cases where RUNNING_P2P/etc can logically occur
with vCPU halted.

So.. this vPRI requirement is quite a big deviation. We can certainly
handle it inside the FSM framework, but it doesn't seem backward
compatible. I wouldn't worry too much about defining it now at least

Jason