Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2210772imd; Fri, 2 Nov 2018 07:44:46 -0700 (PDT) X-Google-Smtp-Source: AJdET5eb892RfdU5sdnAjCBwsdSZixBzKU9vom3JDZ/eosYgihiaGRbl9VRKUGekLNYAC1+EAIG4 X-Received: by 2002:a17:902:201:: with SMTP id 1-v6mr12010856plc.307.1541169886097; Fri, 02 Nov 2018 07:44:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541169886; cv=none; d=google.com; s=arc-20160816; b=cpH2/GwNLoSukTvHBbZUjzgZBilX4yzmDwoZGRwyxS93s9h6z9ha5byqAgQXvD40ts 5SCyXUP6idx21SvxHHgooxOMyW/NO5p5olFunE+d5hnAPNw22c/U061unIl0UUtUk2MG UAg85ZlPv4go2+1CnJ93+7TSyFYCh0bdwah7iUpCirgrdlfa5gCfoorPg5uN3OqIYkGl pklVDOP/lZ0nWQXytJ21T/K+bktgz7Q1ORiglqg8Hf1zbg7TrR0qMx4mpzSoAht3sW9G DAoEcc0thsgzKeAziv3QOqfW/CLILlR1ztIIJxr2AvteZvhGE6BBDreJIIFi5IKMdANn zGNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=+euNJpRHyVcv2rBZ09rZuAsQYr4X22QTmJnsyjrLcQA=; b=EoYjeIDpwaEe0F9JcALx8y/rUpi8NxYqRU5vknq/C8Gq0XVCrYlTjg1EhYBYL0kUzx tINUid5mnvou9kEY/oX+EwuCgH8EyfSCf1lC09z91/lnbQJy4j+pY+TESb+DhKaS8qBQ nZR/XYcEqHEDrFRDDUUkSyfdDO55KW3XAb8Np2c6eXKulB4JoKbkcueaNXw2JGQEqN4V 6c8hygKL3VIYzLEFldLIYrUVuKeSsz+wz5rYhrIUI4PoUbKQpb0tL7mIBPKt8tciGo7p CGKhdE5XQtM5OZ+VxrYilj7q5dbmIw8rNW0RhN78hEwvDQOBcOiQD/L0XWS/r0JjpC9w dheQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 134-v6si34467431pfu.273.2018.11.02.07.44.31; Fri, 02 Nov 2018 07:44:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727977AbeKBXt7 (ORCPT + 99 others); Fri, 2 Nov 2018 19:49:59 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:34466 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726557AbeKBXt7 (ORCPT ); Fri, 2 Nov 2018 19:49:59 -0400 Received: from [IPv6:2a02:8109:92c0:207d:adf1:b546:cba2:bcad] (unknown [IPv6:2a02:8109:92c0:207d:adf1:b546:cba2:bcad]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: robertfoss) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 0984D27DFBE; Fri, 2 Nov 2018 14:42:36 +0000 (GMT) Subject: Re: [PATCH 2/5] drm/virtio: add uapi for in and out explicit fences To: Emil Velikov Cc: David Airlie , "Linux-Kernel@Vger. Kernel. Org" , ML dri-devel , "open list:VIRTIO GPU DRIVER" , Gustavo Padovan , Gerd Hoffmann , Emil Velikov References: <20181025183739.9375-1-robert.foss@collabora.com> <20181025183739.9375-3-robert.foss@collabora.com> <3a8a03d6-a544-b9f3-15a2-f6a2411bdb28@collabora.com> From: Robert Foss Message-ID: <2a3f25cc-d14c-c0bb-152c-03a6a154df6a@collabora.com> Date: Fri, 2 Nov 2018 15:42:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Emil, On 2018-11-02 14:34, Emil Velikov wrote: > On Thu, 1 Nov 2018 at 12:56, Robert Foss wrote: >> On 2018-10-31 10:38, Emil Velikov wrote: >>> Hi Rob, >>> >>> On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote: >>>> >>>> Add a new field called fence_fd that will be used by userspace to send >>>> in-fences to the kernel and receive out-fences created by the kernel. >>>> >>>> This uapi enables virtio to take advantage of explicit synchronization of >>>> dma-bufs. >>>> >>>> There are two new flags: >>>> >>>> * VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd. >>>> * VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd >>>> >>>> The execbuffer IOCTL is now read-write to allow the userspace to read the >>>> out-fence. >>>> >>>> On error -1 should be returned in the fence_fd field. >>>> >>>> Signed-off-by: Gustavo Padovan >>>> Signed-off-by: Robert Foss >>>> --- >>>> Changes since v2: >>>> - Since exbuf-flags is a new flag, check that unsupported >>>> flags aren't set. >>>> >>>> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++ >>>> include/uapi/drm/virtgpu_drm.h | 13 ++++++++++--- >>>> 2 files changed, 15 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c >>>> index d01a9ed100d1..1af289b28fc4 100644 >>>> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c >>>> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c >>>> @@ -116,9 +116,14 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device *dev, void *data, >>>> struct ww_acquire_ctx ticket; >>>> void *buf; >>>> >>>> + exbuf->fence_fd = -1; >>>> + >>> Move this after the sanity checking. >> >> Agreed. Fixed in v4 >> >>> >>>> if (vgdev->has_virgl_3d == false) >>>> return -ENOSYS; >>>> >>>> + if ((exbuf->flags & ~VIRTGPU_EXECBUF_FLAGS)) >>>> + return -EINVAL; >>>> + >>> I assume this did this trigger when using old userspace? >> >> No, not as far as I'm aware. This check is there to prevent userspace from >> polluting the bitspace of flag, so that all free bits can be used for new flags. >> >> As far as I understand this is pointed out by a drm driver development document >> written by danvet, which I unfortunately can't seem to find the link for at the >> moment. >> > Yes that is correct. What I was asking is: > > Does a kernel with this patch, work with mesa lacking the corresponding updates? > I'd imagine things work just fine. Yes it does! > > -Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >