Re: [PATCH RFC v2 04/16] vfio-user: connect vfio proxy to remote server

[John Johnson <john.g.johnson@oracle.com>]

> On Sep 8, 2021, at 11:29 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> 
> On Thu, Sep 09, 2021 at 05:11:49AM +0000, John Johnson wrote:
>> 
>> 
>> 	I did look at coroutines, but they seemed to work when the sender
>> is triggering the coroutine on send, not when request packets are arriving
>> asynchronously to the sends.
> 
> This can be done with a receiver coroutine. Its job is to be the only
> thing that reads vfio-user messages from the socket. A receiver
> coroutine reads messages from the socket and wakes up the waiting
> coroutine that yielded from vfio_user_send_recv() or
> vfio_user_pci_process_req().
> 
> (Although vfio_user_pci_process_req() could be called directly from the
> receiver coroutine, it seems safer to have a separate coroutine that
> processes requests so that the receiver isn't blocked in case
> vfio_user_pci_process_req() yields while processing a request.)
> 
> Going back to what you mentioned above, the receiver coroutine does
> something like this:
> 
>  if it's a reply
>      reply = find_reply(...)
>      qemu_coroutine_enter(reply->co) // instead of signalling reply->cv
>  else
>      QSIMPLEQ_INSERT_TAIL(&pending_reqs, request, next);
>      if (pending_reqs_was_empty) {
>          qemu_coroutine_enter(process_request_co);
>      }
> 
> The pending_reqs queue holds incoming requests that the
> process_request_co coroutine processes.
> 


	How do coroutines work across threads?  There can be multiple vCPU
threads waiting for replies, and I think the receiver coroutine will be
running in the main loop thread.  Where would a vCPU block waiting for
a reply?  I think coroutine_yield() returns to its coroutine_enter() caller.

							JJ