RE: [PATCH v8] introduce vfio-user protocol specification

[Thanos Makatos]

> > 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.