Re: [Qemu-devel] [virtio-comment] Re: [RFC 1/2] spec/vhost-user: Introduce secondary channel for slave initiated requests

[Wei Wang]

On 04/25/2017 07:55 PM, Maxime Coquelin wrote:
> Hi Wei,
>
> On 04/24/2017 10:05 AM, Wei Wang wrote:
> > On 04/14/2017 05:03 PM, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Tue, Apr 11, 2017 at 5:53 PM Maxime Coquelin 
> > > <address@hidden <mailto:address@hidden>> wrote:
> > >
> > >     Hi Marc-André,
> > >
> > >     On 04/11/2017 03:06 PM, Marc-André Lureau wrote:
> > >     > Hi
> > >     >
> > >     > On Tue, Apr 11, 2017 at 12:10 PM Maxime Coquelin
> > >     > <address@hidden <mailto:address@hidden>
> > >     <mailto:address@hidden
> > >     <mailto:address@hidden>>> wrote:
> > >     >
> > >     >     This vhost-user specification update aims at enabling the
> > >     >     slave to send requests to the master using a dedicated socket
> > >     >     created by the master.
> > >     >
> > >     >     It can be used for example when the slave implements a device
> > >     >     IOTLB to send cache miss requests to the master.
> > >     >
> > >     >     The message types list is updated with an "Initiator" 
> > > field to
> > >     >     indicate for each type whether the master and/or slave can
> > >     >     initiate the request.
> > >     >
> > >     >     Signed-off-by: Maxime Coquelin <address@hidden
> > >     <mailto:address@hidden>
> > >     >     <mailto:address@hidden
> > >     <mailto:address@hidden>>>
> > >     >
> > >     >
> > >     > This is very similar to a patch I proposed for shutdown slave
> > >     initiated
> > >     > requests:
> > >     > 
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg00095.html
> > >
> > >     Indeed, thanks for pointing this out, I wasn't aware of your 
> > > series.
> > >
> > >     I find your proposal of having dedicated messages types
> > >     (VHOST_USER_SLAVE_*) cleaner.
> > >
> > > ok
> > >
> > >     Are you ok if I handover your patch, and replace
> > >     VHOST_USER_SET_SLAVE_FD to VHOST_USER_SET_SLAVE_REQ_FD?
> > >
> > >
> > > They are very similar, I suggest you update your patch with the best 
> > > of both.
> > >
> > > I suppose you came to the same conclusion with me that trying to 
> > > make the communication both ways on the same fd would be quite 
> > > difficult, although it's a bit strange that the qemu implementation 
> > > forces the design of the protocol in some direction.
> > > --
> >
> > When would you get the implementation patch ready? Thanks.
>
> I sent second version of the RFC on April 14th, which comprises the
> implementation:
> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg02467.html

Thanks, Maxime. I was trying to make the connection bidirectional
(https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg02617.html),
which was reported as problematic due to the possibility of race (though
I think it can be solved by re-sending the msg in that rare case).

Anyway, hope to see you guys' second channel based implementation to
be merged soon. I would also consider to switch to use it then.

Best,
Wei