[PATCH 1/2] drm/virtio: Create Dumb BOs as guest Blobs

[Gerd Hoffmann]

  Hi,

> > No.  VIRTGPU_BLOB_FLAG_USE_SHAREABLE means the host (aka device in virtio
> > terms) *can* create a shared mapping.  So, the guest sends still needs to send transfer
> > commands, and then the device can shortcut the transfer commands on the host side in
> > case a shared mapping exists.
> [Kasireddy, Vivek] Ok. IIUC, are you saying that the device may or may not create a shared
> mapping (meaning res->image) and that the driver should not make any assumptions about
> that and thus still do the transfers and flushes?

Yes.

> Also, could you please briefly explain what does
> VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE mean given that the spec does not
> describe these blob_flags clearly? This is what the spec says:

This matters for VIRTIO_GPU_BLOB_MEM_HOST3D resources only.
VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE indicates the guest wants map the
resource for cpu access.  When the flag is not set only gpu access is
needed.

> And, what should be the default blob_flags value for a dumb bo if the
> userspace does not specify them?

Just VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE is fine for
VIRTIO_GPU_BLOB_MEM_GUEST.

> [Kasireddy, Vivek] With the patches I tested with:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-03/msg09786.html

Saw the series, not looked in detail yet.

> I noticed that if we do not have res->image and only have res->blob, we have to 
> re-submit the blob/dmabuf and update the displaysurface if guest made updates to it 
> (in this case same FB)

flush must call dpy_gfx_update() or dpy_gl_update().

Oh, and make sure you use qemu master (or 6.0-rc).  In 5.2 + older
display updates might not work properly due to a missing glFlush()
in qemu.

take care,
  Gerd