linux-kernel - Re: [PATCH v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Feb 2019 08:23:41 +0100
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Gurchetan Singh <gurchetansingh@...omium.org>
Cc:     ML dri-devel <dri-devel@...ts.freedesktop.org>,
        David Airlie <airlied@...ux.ie>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:VIRTIO GPU DRIVER" 
        <virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH v2 5/6] drm/virtio: drop fencing in
 virtio_gpu_resource_create_ioctl

On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:
> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann <kraxel@...hat.com> wrote:
> >
> > There is no need to wait for completion here.
> >
> > The host will process commands in submit order, so commands can
> > reference the new resource just fine even when queued up before
> > completion.
> 
> Does virtio_gpu_execbuffer_ioctl also wait for completion for a host response?

No.

But you pass in a list of objects (drm_virtgpu_execbuffer->bo_handles)
used.  They will all get reserved, so you can use DRM_IOCTL_VIRTGPU_WAIT
on any of these objects to wait for completion.

Recently the driver got support for returning a fence fd for the
execbuffer, which you can also use to wait for completion in case your
kernel is new enough.

> From the guest driver perspective, a fence is just implemented has a
> virtio 3D resource.
> 
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L787
> 
> The DRM_IOCTL_VIRTGPU_WAIT ioctl essentially waits for the reservation
> objects associated with that fence resource to become available.  So
> the flow is:
> 
> virtio_gpu_execbuffer_ioctl
> virtio_gpu_resource_create_ioctl with fence resource
> virtio_gpu_wait_ioctl with that fence resource --> associated with a
> GL wait on the host side

Oh.  /me looks surprised.
Wasn't aware that userspace is doing *that*.

> Does this change modify this sequence of events?

Yes.  DRM_IOCTL_VIRTGPU_WAIT will not wait any more.  Guess I have to
scratch the patch then ...

cheers,
  Gerd