Re: [virtio-comment] Re: [PATCH 1/2] virtio-gpu: add resource create blob

[Chia-I Wu <olvaffe@gmail.com>]

On Wed, Apr 29, 2020 at 2:28 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>   Hi,
>
> > > Do we need separate items (HOSTSYS/HOST3D) for these?  Shouldn't this be
> > > a host implementation detail the guest doesn't need to worry about?
> >
> > Yes, separate items are not needed and could indeed be an host
> > implementation detail.  Right now, the drm uapi has VIRTGPU_BLOB_MEM_HOST /
> > VIRTIO_GPU_BLOB_MEM_HOST_GUEST and the kernel separates to HOST{SYS,3D} and
> > does various checks.
> >
> > https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commit/0ccb47d5150a2978d179d0c44ef3285541c8964c
> >
> >
> > The reasoning is since there's no RESOURCE_CREATE_BLOB2D
> > or RESOURCE_CREATE_BLOB3D, the separation captures that difference in an
> > explicit API level.  That way, the blob id is only allowed with HOST3D.
>
> I think we can also simply define "blob id is only allowed virgl=on", no
> need for a separate command.

With a single command, can blob_id be 0 when virgl=on?  Does the host
have enough info to know where to allocate from?

It seems we want HOSTSYS such that we can create dumb bos that are not
shadowed.  How about favoring GUEST for that use case instead?  Some
VMMs cannot support mapping a HOSTSYS into the guest.  The downside
would be that VMMs only see a dumb bo as an array of
virtio_gpu_mem_entry.  VMMs that need a linear mapping would need
something like udmabuf.

VIRTIO_GPU_CMD_SET_SCANOUT_BLOB below makes sense.