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
