[virglrenderer-devel] coherent memory access for virgl

Gerd Hoffmann kraxel at redhat.com
Fri Mar 15 07:31:31 UTC 2019


  Hi,

> > Hmm.  That'll be tricky.  It's the guest which creates resources by
> > design.  Easiest for host -> guest data xfer would be the guest still
> > creates the resource, but the host will fill it with data (from the
> > camera for example).
> 
> Yeah, that would make most sense from an arch point of view, but I know that
> VPUs can impose big constraints on how a buffer has to be allocated and I
> guess camera IPs do as well.

VPUs?  Do you mean GPUs?

Allowing host-allocated buffers is planned, we'll need that for coherent
memory support where effectively the host GPU driver has to do the
allocation.  But it is still the guest who manages the resource (assign
resource id, specify size and format, ...).

> In both those cases, I think that though the host kernel would do the
> allocation and the guest could get a FD that ultimately refers to those
> buffers, things could work fine because in general the guest wouldn't need
> to access its contents by itself. I would expect those buffers to end up
> imported into EGL images in virgl and passed to virglrenderer to be used as
> textures. Or sent back to the compositor for composition.

Passing through a handle might work.

> If the guest needs to actually access the contents of those buffers, then
> maybe we can do something (copy?) in the mmap implementation for those FDs?

That is a hard problem.  All the buffer metadata goes over the protocol
stream, which is passed through transparently by virtio-gpu driver
(guest side) and qemu (host side).  So neither virtio-gpu nor qemu know
anything about the buffer in case it wasn't created by virtio-gpu.

> Another use case for FD passing from host to guest would be to pass a
> "child" stream. For example, when a client in the guest receives a drag and
> drop event from the compositor, it will get a FD corresponding to a pipe
> from which it can read the data offered. The proxy in the host would be able
> to splice the pipe from the compositor into a virtio-gpu stream FD for the
> client to read().

That should be doable.  It'll be just another stream.

cheers,
  Gerd



More information about the virglrenderer-devel mailing list