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
