> > Are there rules for avoiding deadlock between client->server and > > server->client messages? For example, the client sends > > VFIO_USER_REGION_WRITE and the server sends > VFIO_USER_VM_INTERRUPT > > before replying to the write message. > > > > Multi-threaded clients and servers could end up deadlocking if > > messages are processed while polling threads handle other device activity > (e.g. > > I/O requests that cause DMA messages). > > > > Pipelining has the nice effect that the oldest message must complete > > before the next pipelined message starts. It imposes a maximum issue > > depth of 1. Still, it seems like it would be relatively easy to hit > > re-entrancy or deadlock issues since both the client and the server > > can initiate messages and may need to wait for a response. > > It's certainly the case that implementation-wise right now these are issues, > at > least on the library side. I think I'm probably OK with requiring responses to > be provided prior to async messages like VM_INTERRUPT.
I think re-entrancy/deadblock issues are not spec-related but can be implementation specific. In your example, the client can't assume that simply because it sent a REGION_WRITE message the only message the server will send will be the reply: it might as well be a VM_INTERRUPT or DMA_READ message.
