[virglrenderer-devel] coherent memory access for virgl

[Gerd Hoffmann]

On Wed, Mar 13, 2019 at 08:40:00AM +0100, Tomeu Vizoso wrote:
> On 3/13/19 8:34 AM, Gerd Hoffmann wrote:
> >    Hi,
> > 
> > > > > That'll probably work best.  Also a virtio protocol extension.
> > > > 
> > > > Ok, then if you think this is the correct approach, I will work on
> > > > rebasing the series below:
> > > > 
> > > > https://lkml.org/lkml/2018/1/26/311
> > > 
> > > Hi Gerd,
> > > 
> > > do you have any remaining concerns about this approach?
> > 
> > Don't remember the details.  Can you just post (or mail privately) what
> > you have right now, so I can have a look at it?
> 
> I haven't done any further work since I last sent
> https://lkml.org/lkml/2018/1/26/312 . Please tell me if anything isn't clear
> from the cover letter and patches.

Ok, looking again.

I guess we should start with just the virtio protocol header changes and
the virtio-gpu ioctl changes.

On the virtio protocol:

 * I'd suggest to take virtio_vsock.h, then simplify the messages
   (addressing for example) and add the fields we need to pass gem
   buffer handles.
 * Using client_fd as connection identifier isn't going to fly.  File
   handles are not unique, each process has its own fd namespace.
 * rx struct looks strange.  You can have protocol buffers following
   the header for both tx and rx.  data + pfns should not be needed.
 * Not sure winsrv is a great name for this.  I can imagine people
   find other use cases for this.
 * On connect we probably want allow indicating the protocol we want
   run, so messages are forwarded to the correct server/proxy on the
   host side.

On the ioctls:

 * The connect ioctl can just return the file handle.
 * Do we actually need a RX ioctl?  We could support read() +
   write() on the file handle returned by connect.

Idea:

 * Can we hand out an socket file handle to userspace, so the sendmsg
   syscall works?  We don't need a TX ioctl then for file descriptor
   passing.  As far I know netlink uses sockets for kernel <-> userspace
   communication too, so there shouldn't be fundamental roadblocks.
   Didn't investigate that in detail though.

cheers,
  Gerd