[virglrenderer-devel] coherent memory access for virgl

[Gerd Hoffmann]

  Hi,

> > Or will the guest have to first ask the host create a
> > resource, then query how big it is, finally map the thing into the guest
> > address space?
> 
> That's right -- though the "compressed size" and the "linear size" may
> be different.
> 
> The proposed mechanism on the host for mapping is gbm_bo_map(..),
> which does de-tiling and returns a map-time stride.  We could emulate
> those semantics.  The size given to mmap on the guest would be
> (box_height * map_stride).

Ah, that clarifies things alot.  Should have looked into the mesa source
code earlier ...

So, the guest's TRANSFER_TO_HOST request will be processed by
virglrenderer this way:

  (1) gbm_bo_map(GBM_BO_TRANSFER_WRITE)
  (2) copy data from guest memory to mapping
  (3) gbm_bo_unmap()

Depending on the format and possibly other factors (1) might or might
not map the bo directly.  In case it is not mapped directly
gbm_bo_unmap() will update the bo and convert (tile/compress) the data
if needed.

In case of coherent buffers the bo will be mapped directly and the unmap
call is not needed to make the changes visible to the gpu.

Correct?

So, yes, we could create a gbm_bo_map/unmap like interface at virtio
protocol level, so the guest would ...

   (1) MAP
   (2) write to mapping
   (3) UNMAP

.. instead of ...

   (1) ATTACH_BACKING
   (2) TRANSFER_TO_HOST
   (3) DETACH_BACKING

I think the guest doesn't need to know which modifiers are used on the
host side then, because the host-side gbm_bo_map/gbm_bo_unmap calls will
tile/detile/compress/uncompress so it'll be transparent to the guest.

Alternatively we could map the tiled/compressed bo as-is into the guest,
then have gbm_bo_map/gbm_bo_unmap calls in the guest handle the
tile/detile/compress/uncompress.  Is it possible in the first place to
map the raw bo on all hardware?  Would that allow to skip the roundtrip
to the host for map/unmap?

> It's possible the protocol doesn't need to be amended.  We call
> TRANSFER_FROM_HOST before we map the buffer, which potentially allows
> us a way to calculate the correct mmap() size:
> 
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/virgl/virgl_texture.c#n192
> 
> But we comment out the stride in TRANSFER_FROM_HOST / TRANSFER_TO_HOST:
> 
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#n288
> 
> In theory, since it's never been used, we can define the stride to be
> an output of the ioctl.

That might work at ioctl level, but not at virtio protocol level.

> We can add even more flags to DRM_VIRTGPU_RESOURCE_INFO (i.e,
> TRANSFER_STRIDE_DIFFERENT) since for most host buffers map_stride ==
> compressed_stride, so we can avoid vm-exits associated with
> TRANSFER_FROM_HOST / TRANSFER_TO_HOST when only need to mmap().  Or we
> can extend the protocol.

Hmm, that assumes we have the guest's gbm_bo_map/gbm_bo_unmap handle
tile/detile/compress/uncompress, correct?

> > Or qemu can pass the udmabuf handle to virglrenderer.
> >
> > The later has the advantage that virglrenderer can possibly do more with
> > the dmabuf than simply mmap()ing it (specifically let the gpu driver
> > import it).  The former has the advantage that it works without
> > virglrenderer changes.
> 
> Remember, we can't import multi-level textures into GL.
> 
> For single-level linear textures, there's the issue of stride /
> alignment -- we can't assume bytes-per-pixel * width will work.  I've
> seen EGL_EXT_image_dma_buf_import fail when every plane isn't 64-byte
> aligned, for example.

Well, virglrenderer can still fallback to mmap(dmabuf) in case the
direct import doesn't work for whatever reason.

> But for KMS, I can imagine scenarios where it can change.  For my
> setup, guest kms also advertises only one primary plane (XR24 AR24
> BX24 BA24 RX24 RA24 XB24 AB24) all the time.  If the virtio-kms driver
> can change what it advertises, and userspace queries KMS based on
> resize-events, maybe it can work.

I don't think this is possible.  The list of supported formats is a
fixed property of the plane, and I think userspace will never try to
re-read that either.

> We could in theory even support overlays inside the guest...

Yes, we could.

cheers,
  Gerd