Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v2)

[Gerd Hoffmann <kraxel@redhat.com>]

> > +
> > +       if (vgdev->has_resource_blob) {
> > +               params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> > +               params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
> >
> 
> This creates some log spam with crosvm + virgl_3d + vanilla linux, since
> transfers don't work for guest blobs.  Two options:
> 
> a) Add vgdev->has_virgl_3d check and don't create a guest blob in that case.
> b) The interactions between TRANSFER_TO_HOST_2D and VIRTGPU_BLOB_MEM_GUEST
> are a bit under-defined in the spec.

Indeed.

> Though since you don't have a host
> side resource, you can safely skip the transfer and crosvm can be modified
> to do the right thing in case of RESOURCE_FLUSH.

IIRC the VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag means that the host *can*
create a shared mapping (i.e. the host seeing guest-side changes without
explicit transfer doesn't cause problems for the guest).  It doesn not
mean the host *must* create a shared mapping (note that there is no
negotiation whenever the host supports shared mappings or not).

So the transfer calls are still needed, and the host can decide to
shortcut them in case it can create a shared mapping.  In case there is
no shared mapping (say due to missing udmabuf support) the host can
fallback to copying.

So I think crosvm should be fixed to not consider transfer commands for
VIRTGPU_BLOB_MEM_GUEST resources an error.

> It makes a ton of sense to have a explicit udmabuf-like flag
> ("BLOB_FLAG_CREATE_GUEST_HANDLE" or "BLOB_FLAG_HANDLE_FROM_GUEST" -- want
> to host OS agnostic -- any other ideas?), especially with 3d mode.

Why?  Can't this be simply an host implementation detail which the guest
doesn't need to worry about?

take care,
  Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel