Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3140745ybd; Fri, 28 Jun 2019 03:36:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVP+G36OWhr/d1Kw6BDn+TIbqotD/P7uD+UnSDBQC2hdCb+ZoYGJyPFEIllfMykcnX/dmU X-Received: by 2002:a17:902:341:: with SMTP id 59mr10677087pld.20.1561718167527; Fri, 28 Jun 2019 03:36:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561718167; cv=none; d=google.com; s=arc-20160816; b=b5tp7WvfUzyrGwYZ98zkTrFVJB0RGz5uwtRvlO3FNmarRxHFem+ErOUeQfpqzr6g71 RE0ovzf9nrcv736L2myaTlDASEqrSOkodi0koK6sSQc+9yUvjttbosFGUZQ4IwHf5d87 DzyxsxztJCd9JDYEcJhEeKIvxmI4kJz5zFnNFXeCVECiE7CJPEBSqY7bt0CUFaKB/ymi WAwYojrBRpRUhN5TUkNAuIrCBLVW8Koj2h+2FqThdiQIgTzhO4te5sEoXXJYORqYLcM1 T1JUSlZTJqgc+hYpDTdTOcgquMZuNB3gRRzxMp7O6tDBVxC2k2K66c8jxCfqdWd5T7uS MGUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VhRK3su/TZl21z9ZnYou+fwtz4uMy6jwl3QK1NLtRiY=; b=d/ncq3szM5c/olXlUCINEVlpqkV2nwcOxq2JZfSvF/aNk9UlQ/v+MLbck8JXwTAwjy 8LZ46Hr11qsdnPne9S9i0QpZv3cuYCGVlqmFdLsNRaBM84Rn/XnKsTjdbBBWcmdOeEXP /xZAwL4KrqyyKZtp4WfWO3lfb6WL2MOLs41iBG/AiZ/+ybAzIJ0ZjWcqbzgb98O6p34Z TeXrggGz00CatOqFsjinR+ePjoyEJ1cferBJKkQ3dw54a5MfL5+Exve+cMo4QWgCwSJl Mky8VU+D8ent2i3wwAJS6zWaGwgJSwzSOOFtNC3HYXoTb6e0sgv10nKTQK/8+4ImMSLt 8rSA== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y5si1628492pgv.390.2019.06.28.03.35.50; Fri, 28 Jun 2019 03:36:07 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726833AbfF1KeR (ORCPT + 99 others); Fri, 28 Jun 2019 06:34:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38986 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726550AbfF1KeQ (ORCPT ); Fri, 28 Jun 2019 06:34:16 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3CFBD3082E55; Fri, 28 Jun 2019 10:34:14 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-96.ams2.redhat.com [10.36.116.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id D77B05C70C; Fri, 28 Jun 2019 10:34:13 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id D90AF16E05; Fri, 28 Jun 2019 12:34:12 +0200 (CEST) Date: Fri, 28 Jun 2019 12:34:12 +0200 From: Gerd Hoffmann To: Chia-I Wu Cc: ML dri-devel , David Airlie , open list , "open list:VIRTIO GPU DRIVER" Subject: Re: [PATCH v4 08/12] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing Message-ID: <20190628103412.f2n7ybp3qtxbhdk4@sirius.home.kraxel.org> References: <20190620060726.926-1-kraxel@redhat.com> <20190620060726.926-9-kraxel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 28 Jun 2019 10:34:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > > @@ -120,9 +120,9 @@ struct virtio_gpu_vbuffer { > > > > char *resp_buf; > > int resp_size; > > - > > virtio_gpu_resp_cb resp_cb; > > > > + struct virtio_gpu_object_array *objs; > This can use a comment (e.g., objects referenced by the vbuffer) IMHO this is obvious ... > > void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev, > > void *data, uint32_t data_size, > > - uint32_t ctx_id, struct virtio_gpu_fence *fence); > > + uint32_t ctx_id, struct virtio_gpu_fence *fence, > > + struct virtio_gpu_object_array *objs); > Can we keep fence, which is updated, as the last parameter? Fixed. > > + if (buflist) { > > + for (i = 0; i < exbuf->num_bo_handles; i++) > > + reservation_object_add_excl_fence(buflist->objs[i]->resv, > > + &out_fence->f); > > + drm_gem_unlock_reservations(buflist->objs, buflist->nents, > > + &ticket); > > + } > We used to unlock after virtio_gpu_cmd_submit. > > I guess, the fence is considered signaled (because its seqno is still > 0) until after virtio_gpu_cmd_submit. We probably don't want other > processes to see the semi-initialized fence. Good point. Fixed. > > out_memdup: > > kfree(buf); > > out_unresv: > > - ttm_eu_backoff_reservation(&ticket, &validate_list); > > -out_free: > > - virtio_gpu_unref_list(&validate_list); > Keeping out_free to free buflist seems just fine. We don't need the separate label though ... > > + drm_gem_unlock_reservations(buflist->objs, buflist->nents, &ticket); > > out_unused_fd: > > kvfree(bo_handles); > > - kvfree(buflist); > > + if (buflist) > > + virtio_gpu_array_put_free(buflist); ... and the buflist is released here if needed. But we need if (buflist) for drm_gem_unlock_reservations too. Fixed. > > - > > - list_del(&entry->list); > > - free_vbuf(vgdev, entry); > > } > > wake_up(&vgdev->ctrlq.ack_queue); > > > > if (fence_id) > > virtio_gpu_fence_event_process(vgdev, fence_id); > > + > > + list_for_each_entry_safe(entry, tmp, &reclaim_list, list) { > > + if (entry->objs) > > + virtio_gpu_array_put_free(entry->objs); > > + list_del(&entry->list); > We are clearing the list. I guess list_del is not needed. > > + free_vbuf(vgdev, entry); This just shuffles around the code. Dropping list_del() is unrelated and should be a separate patch. Beside that I'm not sure it actually can be dropped. free_vbuf() will not kfree() the vbuf but keep it cached in a freelist instead. cheers, Gerd