> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, January 26, 2022 11:33 PM > > 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. >From this angle, yes. > > 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 > Now I see your point. Yes, we have to do some incompatible way to support vPRI. In the end we need part of arc in FSM can run with active vCPUs. Thanks Kevin
