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 DC820EB64D8 for ; Thu, 22 Jun 2023 14:42:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E01C8D0002; Thu, 22 Jun 2023 10:42:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3692A8D0001; Thu, 22 Jun 2023 10:42:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BB6E8D0002; Thu, 22 Jun 2023 10:42:24 -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 05EA78D0001 for ; Thu, 22 Jun 2023 10:42:24 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B3CE1140182 for ; Thu, 22 Jun 2023 14:42:23 +0000 (UTC) X-FDA: 80930649366.22.D39D9A6 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) by imf03.hostedemail.com (Postfix) with ESMTP id 9D3A92001C for ; Thu, 22 Jun 2023 14:42:20 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=q9rm3gIU; dmarc=pass (policy=quarantine) header.from=amd.com; spf=pass (imf03.hostedemail.com: domain of Christian.Koenig@amd.com designates 40.107.236.40 as permitted sender) smtp.mailfrom=Christian.Koenig@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687444940; 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=os7X98DgxIfN7ME8lo4DWq4txD8YTEQXFMigNgT3ZZY=; b=A1FBIJBTeqBA10lqS09QFrAWuSwbOyyu+fBbWwFdTonHEIpsddL2yZybjDC5dOOC+IMz8q 3ZWaSIguXQ2tpPJDmUahQ+mdTgiLLHfj8gJ1pczC0oKhQCVh9qb97lwKf5ZYe2joznet9x iaU1tpvRwlKVTWvrWy6KnyFYySpaZPI= ARC-Authentication-Results: i=2; imf03.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=q9rm3gIU; dmarc=pass (policy=quarantine) header.from=amd.com; spf=pass (imf03.hostedemail.com: domain of Christian.Koenig@amd.com designates 40.107.236.40 as permitted sender) smtp.mailfrom=Christian.Koenig@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1687444940; a=rsa-sha256; cv=pass; b=ifvtW7U0gR7y8fX0PeUaNBQOh0YajYWpHpjWTJaKZ60GoWqyKWXIMSKCkRUOcXYDbdLSxy zWvE59SRGV/S/luf4rcpkrvvrHRPhw9JNUldkZtt5R3faHkbQdy3uyaS05iSOJCC520Chh 0MfZ8RDqRbWdFKXUNleF/BOU0RH/IqM= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B9HKkzbFnp+JuN8iUji97I+0Uuhd+FeWhQ3nJ5QDKyq6Eg5EpaVhBqfwFMHgTIoGgkiPikQbzmNDB/dFD4h7MnwxV1Jl0EwyBJa2GKzilkBbSeDBJ2WdQrIqnt1Lx0LDLmO1G21CGY7zX29H605bdqwY6CTJjmX3wKK0Uwd35CMB46S9nvH+eT0qvrywRQU3B1ep6AoipLVrzFzCYV7ve4Gv6jei96u+ZjCXG4tDNiZiFQvtjCl9FKx2HJCmKo1R8lkvxxYn8UWLeYxa7rmCQ5kuDNWTGPW1QaOdIrqy6NYZmpxvty8U+9Oos4skkfY2Cffs8CKbBwwDDkRm941pEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=os7X98DgxIfN7ME8lo4DWq4txD8YTEQXFMigNgT3ZZY=; b=DUzoz5hXcbu+ygJHRgbfpyirC2mi8iS3zp4XrOIQrdjM4uFVMdriy2JUx25UslhPmquXK5fdaO6uK7wx4jM1DdrXvrpj7DYkh7zTa9ObbOLJMeUk8joFRuiJwNgYhIJSnBycnETwA/Lr9blvHRwbq2iWQmUciEKKMuBaomdH1IKzA/ELzuWRtjU1DJGyyJxenVa1A5jCazDG4bMDRxTroKUTuugaT6Vkrkkbjb57oGp+S7TQEvXfRfSxUQpYkMD3HfpPm8P+W3Dewc1FIBQjmeZMGDGwcn7YlRlfGqy8AzNc0/i/a4GXr959ar9rpFMyOWB7xddrCt24JpICLTa6Ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=os7X98DgxIfN7ME8lo4DWq4txD8YTEQXFMigNgT3ZZY=; b=q9rm3gIUIoEjqV14aggf9lPV38vMQc/HDLMR3pC47iAx7vov3VAiSBMzfguqAUDhJ+VNeIGTuejW47Sk2AGsXT9Ukq4wSPtd+JJCtbSWNMmBDboiX5DfyoSnB/J2e41qNb0aIWJk1h1tfdUZa2T4TJ+5KQETxf2fwZIMiLYE890= Received: from BN8PR12MB3587.namprd12.prod.outlook.com (2603:10b6:408:43::13) by MW4PR12MB7261.namprd12.prod.outlook.com (2603:10b6:303:229::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.24; Thu, 22 Jun 2023 14:42:17 +0000 Received: from BN8PR12MB3587.namprd12.prod.outlook.com ([fe80::384a:95a4:8819:ee84]) by BN8PR12MB3587.namprd12.prod.outlook.com ([fe80::384a:95a4:8819:ee84%7]) with mapi id 15.20.6521.024; Thu, 22 Jun 2023 14:42:17 +0000 Message-ID: <86ef9898-c4b6-f4c0-7ad3-3ffe5358365a@amd.com> Date: Thu, 22 Jun 2023 16:42:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH drm-next v5 03/14] drm: manager to keep track of GPUs VA mappings Content-Language: en-US To: Danilo Krummrich , 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> <41aecd10-9956-0752-2838-34c97834f0c8@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR3P281CA0187.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a4::15) To BN8PR12MB3587.namprd12.prod.outlook.com (2603:10b6:408:43::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8PR12MB3587:EE_|MW4PR12MB7261:EE_ X-MS-Office365-Filtering-Correlation-Id: b75bbd98-d0da-4f47-a889-08db732ee071 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sDNZqanPoogKWSH5WM7ANNWgcBCU/2pxDYUvsxUtri2Hh7a4/LAa/hyMD0MiGNY5I8jRmh2Jg5//HgbcZH15AHrQNo20zebrVU0UbcSD0msDp1wFfLKT8Hz2O9EgZCrJYk8t+z2Y8PGpuDQTXdDvVFNQbJJ2l9B4qwSMJvl8zGDblRcXMhx/+YaQAyF09MAFA5TMaYRA+KuHuLJ8QaG5I0Mw7pHjDJp6VX+puxk4TBzWzsAC5iWnUL0E0ugUZsBppDzL6jfFe6AlowFzX9estECkewwo1a1XdBBiFbHm5+frtaNhr2+cvfadd6qHMQ7AN5bUQrwqz8UT4fi0ixyS5VfXR8x2jfT0Sb9zXYtfDgLWCyHObc8VeiLrWBQIdYUkeESdY4Z+OWEyDgBzapq9/6pgizRHa629U7oMUgczneWxEYm99a5V9tPX0CtYL8Vl19d2CCzhmQWQR1z/8Y4jqBfzoQYwgTiDKSCJdOVOjRuRdJfqY1v4LuePGRiuAYUIE6w6arKRtky1+6l4VYV1tBhe36WB09G6JK+/niJRK566czuSEiDcxuydMYPzltWayyS07lPWUJemZeNyemT4lpUYq+FaZxr7uFpI4E6Kcx8qDiotei4bF6p//O2cLjSw+16Ly3Zi+dN5ns5rmomZiEvr/xVDLq9oD81trXV/YmE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN8PR12MB3587.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(451199021)(186003)(6506007)(53546011)(6512007)(8676002)(2616005)(66574015)(83380400001)(8936002)(5660300002)(41300700001)(66476007)(66946007)(66556008)(316002)(2906002)(7416002)(6666004)(478600001)(6486002)(4326008)(54906003)(86362001)(31696002)(36756003)(31686004)(921005)(38100700002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y0s0YXVhWFRCcGVHRjl0S0tXZWVxMVBWeCthbnlLVldEQTR1cmYxM3NBQ1BE?= =?utf-8?B?bDFDeDBydE40S0VLMzR5MjA2MEI3dWZMWUJSVFN2VU1zWDh4dEZnQk8yQlJi?= =?utf-8?B?Zy9MQ2w4WEFsSk41UXRRWUttY3Z6ZFdpV1o5UUJHVW5ub3ZSSEQ4Z1NQRzBk?= =?utf-8?B?eVpta3RQd3YrWE5nN0lpNFZqTGlXYmlKSWJYWGVXcCtpRStaY0laaVlVUWVu?= =?utf-8?B?NjBROUcxWU9xUHh2eEp5QllGZ1ExdWxteEpsVGx6VWp2REJQQkk2M0JPd2hq?= =?utf-8?B?aGhVWUlqeDUwb1JOUlJwQnViN0p1NGtaK1lPRUNTZGUvcjJNYTZlK201MjFl?= =?utf-8?B?dloyUGdPMnM3T0R2U0lYeHl3bTd6c2JxaXpCQk9hNDlTdXJMVndISDJSUVgv?= =?utf-8?B?K2h0Wll0d0NqbnRQMmtFUEFVTkgvaVFzTVZOZkZXWWU2S3ZTb0VUWEZIL2k5?= =?utf-8?B?VkhhRCt0ZWlYWTJHQktmam9CRU5lNFJZOVU5Z0Q0Y2lrQ0R5TlJIaU1YdVNJ?= =?utf-8?B?QVVZMUFYcC9MRVlvU2tRcytFdDU0MHh0Szh1ZHJtTkRNUDlhUVNTZUVmVVov?= =?utf-8?B?UDJOcjYxb0J1MHI3RURUQ0xsandrbk1qZEFUSTlGQlZleE9EcUhBMUtIYkt1?= =?utf-8?B?OUZSeXVpU1dnS0ZZWksyUHNwRW9QUHNvTUdDUFl2aTZpb21DTnlSaDdZTzli?= =?utf-8?B?WVVyaCtHRHZmNGVqazhKaktiYStLMEp2OTlDNEx5ZmZ1TEpvWmxYR0liTW4v?= =?utf-8?B?bFMraGUrMGxqVFAwNDZSTjd4ZStYc1hET3A4MHN5eVZjU1NQZ3hqRDZuQVM3?= =?utf-8?B?azNvK3ROY3dVZ0dVb3JCQmxZc1grd0RFalhmbEprZ1NXNUlmK2l3QXJlVDdQ?= =?utf-8?B?Rk1jWVFyQ05md3BPNTVRV1ArV2RaaXRhY2c4cXVkNjhKYmxwbG5SeEVMQzhE?= =?utf-8?B?TE9oNHZ4RjdOY0U1NVVKZk95YzhjMU14V0JnWVQrTDYzbGxZRlgvSjJMd0F5?= =?utf-8?B?TDQ1UEk0czZyakhWMEtlTVlwd3c3cE5Oa0h2aHNtaStNUUtFNE9oT3M1VDAw?= =?utf-8?B?MGhuV3ZOS3UyL3lHWUdTaTFJREdaaEpONTcybDRPRnRyZVhMQkNZRWxrOWVB?= =?utf-8?B?akZCa09VWFo1dU84eDE4M29kdkdCWjVZVGsyUGdnbC83OGpYNm9yWWYzR0ZZ?= =?utf-8?B?VmR5MTFFekx3YTBkSzdRbnJOQ2l4SUhVUnREcTlhRUVEbUtZa0VFMTlEZXJ5?= =?utf-8?B?aWZpOURQenIzQ1k0czJHYzc1azJ0clZVbXBiS0Myb3l4SWZoTWpOaGZuVTkx?= =?utf-8?B?WE9DamcrUURvMEpkK29ueWVGMGQ0YUJvNlBzMUxZeVFoaFZvcWhvRisxNEwv?= =?utf-8?B?MlgrMW4xM1JwaG4wazdkUkxKdnBoRStVSXVBckF4bmFrMVRRTktmd0dLVG9U?= =?utf-8?B?c05jaFIyS1NDMWJqVmh0cmh0NzNTeGRtZ3MrSzFTSXQyWm90WTVXVE8wUXR4?= =?utf-8?B?QmFMRXdnV2FQS2g0ZlMvcW5YWHNyNmNqbkRiNmVlRzd4MXRoRWhtYWdVc2xR?= =?utf-8?B?K1hnQWdnSS9jV3l0dmhTTzVGYXg1cVpsU2FkMHRuY0QwM1QrbWxXN0Nrekcy?= =?utf-8?B?b0I0Nnd3bFRqSmdQZkI0NVYwT1Zzc2ZVcW1nR0dRQkI3NkQ2WXgvQXJmTWZH?= =?utf-8?B?R09FWDJsRmo3YmUwTVBydkhaOG96OWJReXI4UlJ2VHFGdm1XS29nTkRwLzho?= =?utf-8?B?K1RXWHdNdnZoU251ZEhYQUNmQzFoMkFkcW1MeEsvQTF6NG82TFk5a1oxYWdX?= =?utf-8?B?bWdnVGNldGl6QU8wRlBucURKRkljMCtpTFVPd3VJSzVxbWwyY0dpdGpick5z?= =?utf-8?B?cHllZmUralRJZ2J6TWxxT0c3VWdiSk5lM0U0NnFpTkFUbzFtQWtLSzZCL2pa?= =?utf-8?B?NWRMQWtNdWVVZ0ZLcVJJMlJuVDU0U1VtSWhpdEsxdWNsaGJUa3VFREs0VnFp?= =?utf-8?B?WEt6TkluQm5hU0tsREkxbWwzRjNNN25RbWRpTGFDZUgveW5rUnNINXUwRzFs?= =?utf-8?B?TFpSMk4zSzF2alRmeUxEZjZjdHVCSmQwa3IvM3dUWk1YWmdTTTYxc0w2eG5m?= =?utf-8?B?dXJ2VG5aQ05JWmpKdVRKek52UTc1UlVaaG1BWEtaTDNleU5FTmFoa0ZQMU9X?= =?utf-8?Q?MeFoJJg57EfL9c20StSzn/v5chJ6Aa/eYjC5C1neAClt?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: b75bbd98-d0da-4f47-a889-08db732ee071 X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2023 14:42:17.6391 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6NNqLsqUGIfubv8dwtBnroZM3ftqySZau77kbRzDMVBseFO/7q1ddNAnBxNeSSej X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7261 X-Rspamd-Queue-Id: 9D3A92001C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: gq9grqt5jn5am3rozeq6t1m7nfyyr4j5 X-HE-Tag: 1687444940-392733 X-HE-Meta: U2FsdGVkX18noeE6RGZkvcl0OO3y8X5MLSIfF1kBLb8ZB5spqiA8aMGvSTgAXdSuk/jA2w30l/JS8wzzUaaL0Cl9Lq/LSRC6J5sd2sC60MfUcR558Wq7flLtQLsrkXsfIm15hRip/F/V+R8rSlRKvv0L9BkjlOKp1/FjD0lG4/TWvIx54NJFu/gvgMeTbfjj9GAPLa7GPXsaC/IGEV2oIjjN4b305uOfvzeTYmow/w5kv+dSt241Xo8U4/IbT9Dy2U8rr57LlyfPkbNn8OTXl5B6UnZp73RoZEEr8t7OsHBlzi3oy174biPYOCp7hsRGYh3ezfUxWbKZ8XJ1JVG2hcjPHxAaZb5AvBQGtmMGiMfU8f32ddMlXQt2MsvCsCzysCDKjmgGUyLr6nGTU+2rIOvT7pRWoAeYjn10pW6GWR2+upCB+5LST/5hla4+HURjR9C8rsM5a+J3QswtFpR+Xt/bVLIRQomb8dRTurkjFD1Osj0YLpbAzFmkbEq4dE2g71XqPLbPz2kXy2xeMyhyGAnWOBsHNc6ivoKHF2Cx87UivVXnZM0vBEijPuT9o08L64lTRWbyCSejR5YdlSV31ZVmQHmis4OKdfOHuzNRDHRi/DaBA3XP5svHokNQdjkfjG8AqjhxZhhQVgT4u8cbjqS7/DkuWkytMtUDlWh3ixjltj1xfnHvQCqLZbIIUFP9Fu/+uyKcHcPjgDLA0uRBnFHcx35RhRxwCYsIKMMCtSwPJ60TJNMT/iu77yOxOgegs43vg2H1FzWxYLsUAZ8lFVVaJ/i6YQH4Mjvn5xY13CZl3kUpLjEpSrAetN3jrIGmVRu3WUvDYQHKoFSDhx5DlG2bSOvagVnQSjs8hF/XUEudRNoGdQ4pLrD7s9+mwVFhZUCQbYS3Zrz102AADwPqsWktq+JRzYkpjbuqoZ1yv8GW2+9mRCN3nqZr6C2rOUB+zkYYcC7mT7yMogpr/k5 B89JsgSv /MVBNNixgh44f95/m+CCiz533HFGjm79c7wSZfRqZdKgy/09l/27IV9DmBhPmr0Mb4UCu6ama5g/1eDyJAFb9Ox8j9F6aJsYjkw2Wn2wjUYL5OXS/7E/ybXJyUpcVFJqY2rlSF1n4/DsShRfS/6QIPnUFzDRs60ww/JvJj7Uy02LO+DyZnmbKlZaFJrYsV0zzGOKui0eJgoxUK9CgGXI+WS6xcTYyFdqv1vDlo75QLdSN0NY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Am 22.06.23 um 16:22 schrieb Danilo Krummrich: > On 6/22/23 15:54, Christian König wrote: >> Am 20.06.23 um 14:23 schrieb Danilo Krummrich: >>> 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? >> >> Flexibility. For example on amdgpu the mappings of a BO are groups by >> VM address spaces. >> >> E.g. the BO points to multiple bo_vm structures which in turn have >> lists of their mappings. > > Isn't this (almost) the same relationship I introduce with the GPUVA > manager? > > If you would switch over to the GPUVA manager right now, it would be > that every GEM has a list of it's mappings (the gpuva list). The > mapping is represented by struct drm_gpuva (of course embedded in > driver specific structure(s)) which has a pointer to the VM address > space it is part of, namely the GPUVA manager instance. And the GPUVA > manager keeps a maple tree of it's mappings as well. > > If you still would like to *directly* (indirectly you already have > that relationship) keep a list of GPUVA managers (VM address spaces) > per GEM, you could still do that in a driver specific way. > > Do I miss something? How do you efficiently find only the mappings of a BO in one VM? Keep in mind that we have cases where one BO is shared with hundreds of different VMs as well as potentially the number of mappings can be >10k. > >> >> Additional to that there is a state maschine associated with the >> mappings, e.g. if the page tables are up to date or need to be >> updated etc.... >> >>> 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? >> >> Yeah, we have tons of cases like that. But I have no idea how to >> generalize them. > > They could still remain to be driver specific then, right? Well does the mapping has a back pointer to the BO? And can that be optional NULL if there is no BO? Regards, Christian. > >> >>> >>>> >>>> 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. >> >> Oh, no! We also have mappings not backed by a BO at all! For example >> for partial resident textures or data routing to internal hw etc... >> >> You can't be sure that a mapping is backed by a BO at all. > > I fully agree, that's why I wrote "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". > > Mappings not being backed by an actual BO would not be linked to a GEM > of course. > >> >>> >>>> >>>> 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? >> >> Well similar to what amdgpu uses BO -> one structure for each >> combination of BO and VM -> mappings inside that VM > > As explained above, I think that's exactly what the GPUVA manager > does, just in another order: > > BO has list of mappings, mappings have pointer to VM, VM has list (or > actually a maple tree) of mappings. > > You see any advantages or disadvantages of either order of > relationships? For me it looks like it doesn't really matter which one > to pick. > > - Danilo > >> >> Regards, >> Christian. >> >>> >>> - Danilo >>> >>>> >>>> Regards, >>>> Christian. >>>> >>>> >>> >> >