> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, January 25, 2022 9:12 PM > > On Tue, Jan 25, 2022 at 03:55:31AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Saturday, January 15, 2022 3:35 AM > > > + * > > > + * The peer to peer (P2P) quiescent state is intended to be a quiescent > > > + * state for the device for the purposes of managing multiple devices > > > within > > > + * a user context where peer-to-peer DMA between devices may be > active. > > > The > > > + * PRE_COPY_P2P and RUNNING_P2P states must prevent the device > from > > > + * initiating any new P2P DMA transactions. If the device can identify > P2P > > > + * transactions then it can stop only P2P DMA, otherwise it must stop > all > > > + * DMA. The migration driver must complete any such outstanding > > > operations > > > + * prior to completing the FSM arc into either P2P state. > > > + * > > > > Now NDMA is renamed to P2P... but we did discuss the potential > > usage of using this state on devices which cannot stop DMA quickly > > thus needs to drain pending page requests which further requires > > running vCPUs if the fault is on guest I/O page table. > > I think this needs to be fleshed out more before we can add it, > ideally along with a driver and some qemu implementation Yes. We have internal implementation but it has to be cleaned up based on this new proposal. > > It looks like the qemu part for this will not be so easy.. > My point is that we know that usage in the radar (though it needs more discussion with real example) then does it make sense to make the current name more general? I'm not sure how many devices can figure out P2P from normal DMAs. If most devices have to stop all DMAs to meet the requirement, calling it a name about stopping all DMAs doesn't hurt the current P2P requirement and is more extensible to cover other stop-dma requirements. Thanks Kevin