From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5C72EB64D7 for ; Tue, 20 Jun 2023 13:59:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67BA28D0002; Tue, 20 Jun 2023 09:59:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62BC48D0001; Tue, 20 Jun 2023 09:59:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A5FE8D0002; Tue, 20 Jun 2023 09:59:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 37F958D0001 for ; Tue, 20 Jun 2023 09:59:12 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DF184B0D45 for ; Tue, 20 Jun 2023 13:59:11 +0000 (UTC) X-FDA: 80923282902.30.0D00526 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 8858C40004 for ; Tue, 20 Jun 2023 13:59:09 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Po6iXdT5; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687269549; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QTLnyrCbOY1xAfP5SqHK9oZhSTIFzQoN+FT5nbHO/xo=; b=IgX52xn1buDo5K1ViDMUAUCLD2UM9i91XtObDHCxX+M/xMKkQ9Q15jbUuiOhx85GiXDkhW l9mkA0g1wYHUcCvoB7T1p/ECGNfnCoKQqnkUVpiLUv9CL14oHGCKgFjIvl+hI23PJxwB5Y 5jBGcdNOGeta/NdDaair804Cbqlabvs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Po6iXdT5; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf27.hostedemail.com: domain of dakr@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dakr@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687269549; a=rsa-sha256; cv=none; b=rTFUVlRAJN9fL6EBtlfstR4xMu8+81Yd7h+kJ0Cr7Vtf91iic4bIzEtRhYayZa4AToVdWe dQK0E2wop2wQEFVuc5TYC9uAOR+7+QO2tctn8po41t+p/FyP8kY1QXQx1PNVW3eiNjZSC3 yr20FZc7JvoQnT6GLOz1O6UAqauBm14= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687269548; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QTLnyrCbOY1xAfP5SqHK9oZhSTIFzQoN+FT5nbHO/xo=; b=Po6iXdT5DTxUsegb02fk1lJpyzT1Th8RVgzw/+ozWbpkpa8/EeGXPot8x1Hvi7hgKMzAzI Izmp0fZklzU2tho1fJoVUHP3fxmV11Xb6vPxqbBBUWT2ZxebNUgIBlN5+XIAvgATRuDQeL haYcD+WoFpNVVqpWrc/hF54MrpcHQNw= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-645-KE-srfknO2uuy3E8LQ_Ruw-1; Tue, 20 Jun 2023 09:59:05 -0400 X-MC-Unique: KE-srfknO2uuy3E8LQ_Ruw-1 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-51a5296eb8eso1776750a12.2 for ; Tue, 20 Jun 2023 06:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687269544; x=1689861544; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QTLnyrCbOY1xAfP5SqHK9oZhSTIFzQoN+FT5nbHO/xo=; b=mH94/uel/+7Y+0viT8hYc69rUmcdsbr5l6TixOON9twOmY4mLRFf4IBv0G84vjK1ky NrZraawlYjW5bzuRAeY4PE0AHTg91uQSQ47gmA0aF3Uu7KrzrQdLWp68EU+QYoRH5Dlo 9Owxo/NgQj5zjwdKyYsiNkqGtU0g5BgupNTP8ITwFd+WPhxL3WtxCRBqtwAR0EKWmqLN YrFuUZQoDS729XBkaTJmUrOfCqkNDqjDvLlmm89vzHFWWZsJPJxyYsx/n4WI/6tv2XvX oNBxGYUcxNTygfQZB63HoaBhQzqiBpOkcJE4QkqRxSjys9vytSzIjCzXeSErxWNTD8j1 NqHw== X-Gm-Message-State: AC+VfDwsOABMt3H3VjQdDgJB8x33qGv9EqXkPTkWTFefknQCSL/uw9pg HxZY8ovzOba3LKrXcQlN1vl2ER3BUoh22MPjR3mK+7jKDvxUg5ZoVwYF4LlTN3NTqEsGG9UK45a sTdcTCz5rsnM= X-Received: by 2002:aa7:d888:0:b0:51a:23fb:355c with SMTP id u8-20020aa7d888000000b0051a23fb355cmr8076338edq.10.1687269543779; Tue, 20 Jun 2023 06:59:03 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6b5AT6QAAjfNGSFqHnSqiPb5mv+npztwci67WB0CYLQf6lJNAROx+U2HhYdxy7fYnS0gvCQg== X-Received: by 2002:aa7:d888:0:b0:51a:23fb:355c with SMTP id u8-20020aa7d888000000b0051a23fb355cmr8076320edq.10.1687269543440; Tue, 20 Jun 2023 06:59:03 -0700 (PDT) Received: from ?IPV6:2a02:810d:4b3f:de9c:642:1aff:fe31:a15c? ([2a02:810d:4b3f:de9c:642:1aff:fe31:a15c]) by smtp.gmail.com with ESMTPSA id x22-20020aa7dad6000000b0050d83a39e6fsm1278687eds.4.2023.06.20.06.59.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jun 2023 06:59:02 -0700 (PDT) Message-ID: Date: Tue, 20 Jun 2023 14:23:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings To: =?UTF-8?Q?Christian_K=c3=b6nig?= , airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org, corbet@lwn.net, bskeggs@redhat.com, Liam.Howlett@oracle.com, matthew.brost@intel.com, boris.brezillon@collabora.com, alexdeucher@gmail.com, ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org, jason@jlekstrand.net Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Donald Robson , Dave Airlie References: <20230620004217.4700-1-dakr@redhat.com> <20230620004217.4700-4-dakr@redhat.com> From: Danilo Krummrich Organization: RedHat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8858C40004 X-Stat-Signature: zsh97p9t6bddsursq3id9xput59xobr1 X-HE-Tag: 1687269549-93827 X-HE-Meta: U2FsdGVkX18AvW9ioygwWLmP2a9okpCEyiFc4kVBnZrLfNIBM8gMJcKGwJ6M/w/f+o5L5OvX/CcXzCz7CQ2wQe/NINudhkaERWM5FY93UL+Rtsht4H8RIt31NCxSyFXY3OS+v2H6LwOusC/GqXvCVJUj9Vzj6jjTpy9jrnimwNj3KpLU25voqHjNdbmKIkmnG8vBNzssEq/On6fInJ9Rb+oqLfLZ2Kt0nAuWvJdBPFTLStOkFsBIC0mZ+3QS8nb73cpheIGrBbEj6QheGxQRv00aeSrcWZsuK2yZrko5y8rE2sByDdjMyRbCHauUhTOY0uzai5bE0Z61CpFwm38bM2KdS+OEVTqQYH2ok0jxaMPseYPSJkY5iwXC7Lq0Mju++8Wm5iTuA1i2GMj8NCnkKhYH4uZPcAPQDh0wdFPXHvfrQYu0Ny5CrhqAVbF/79i37JDSbiKo5kzp+H3IunLjE7iGvSA0NHOPWuYxzrK0uNYxnmUSgQfJ1Re5ubBpuuW2VK+H4ehJMT1hTRFFT/RhAE2sD77/o0rwRjP/2rV6DU8KVSDvUSFEc2fz7GfNLAlTgf5Uf6bQlBLrgIce1479+S5gVPbLgId9HT3t97lvbpt6wxOfe7DS4jUe5Lq9U+GZwvL4coer8oOJKUG4miWMGa5evlVTjW4EWBUijgM1LkgYIB49Lscq19mKhxaqUQyf2t9ZzXFvBdGbOCV2pS3o9xIakCvJLvYVuaYORpJKn3K0wtsO47HVJvquTmBebdCnLez7iuiPpEHmgYdLdWEyeCC9z760sGVRNEeaWjYvPP7Xz38SIyHJTlDbHHJmiteyLyBVgN9BhQKySJTOD2gCo9d3HCh8mnzX2YfKj/IVjMGDr/MF4Xv1kzDYeKdxT0IeWd6+w2ZbH2TdDQ/RUsWex9P6n1buexv7Y7ftJP83NbAQhpxNSL01vMvEWQMYrlaJK2AV3URFyhQZzslgumR Qj2H8iNo 3AqjWfg09JL7YA1/BF9ksN3zmuhWMURcRAbuPrI5AnPSY4+txurT+npgBVOoZsTWCzh2or9AAhVE0TwC+n5MK2WxqriWh3YC9jpozcbpvxvDciZhakr94CAkZeAxA25bHJX//XXPWa+6OokvOdMZFiqRxsYGRf9fzpHgQIlnjeuFTSj3CzT28nA3cMP4SAAOMDbQMoyvWK8zPqnE7KzAhFFh3QBj6smPT54Qen6sJpiajLVwgFXP4AGmrjF837p3lxVyL3nmnOyi98MMt7+bDwhj9HE8e1RvJi/KXbo+2l3lSw5mXJ6RPRqYX69TzT8SW7vVuwl/vYLrSuQe6UIH2zGihgwMP+YtclFHQI+evYO/4ZcCARosK7YLEFM82dJYtmesS48b6yIoI9wrp6l8bhBLTKUfvX9BtE/MW X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Christian, On 6/20/23 08:45, Christian König wrote: > Hi Danilo, > > sorry for the delayed reply. I've trying to dig myself out of a hole at > the moment. No worries, thank you for taking a look anyway! > > Am 20.06.23 um 02:42 schrieb Danilo Krummrich: >> [SNIP] >> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h >> index bbc721870c13..5ec8148a30ee 100644 >> --- a/include/drm/drm_gem.h >> +++ b/include/drm/drm_gem.h >> @@ -36,6 +36,8 @@ >>   #include >>   #include >> +#include >> +#include >>   #include >> @@ -379,6 +381,18 @@ struct drm_gem_object { >>        */ >>       struct dma_resv _resv; >> +    /** >> +     * @gpuva: >> +     * >> +     * Provides the list of GPU VAs attached to this GEM object. >> +     * >> +     * Drivers should lock list accesses with the GEMs &dma_resv lock >> +     * (&drm_gem_object.resv). >> +     */ >> +    struct { >> +        struct list_head list; >> +    } gpuva; >> + >>       /** >>        * @funcs: >>        * > > I'm pretty sure that it's not a good idea to attach this directly to the > GEM object. Why do you think so? IMHO having a common way to connect mappings to their backing buffers is a good thing, since every driver needs this connection anyway. E.g. when a BO gets evicted, drivers can just iterate the list of mappings and, as the circumstances require, invalidate the corresponding mappings or to unmap all existing mappings of a given buffer. What would be the advantage to let every driver implement a driver specific way of keeping this connection? Do you see cases where this kind of connection between mappings and backing buffers wouldn't be good enough? If so, which cases do you have in mind? Maybe we can cover them in a common way as well? > > As you wrote in the commit message it's highly driver specific what to > map and where to map it. In the end the common case should be that in a VA space at least every mapping being backed by a BO is represented by a struct drm_gpuva. > > Instead I suggest to have a separate structure for mappings in a VA > space which driver can then add to their GEM objects or whatever they > want to map into their VMs. Which kind of separate structure for mappings? Another one analogous to struct drm_gpuva? - Danilo > > Regards, > Christian. > >