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