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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6343CC83F33 for ; Mon, 4 Sep 2023 08:26:20 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 75DF810E10A; Mon, 4 Sep 2023 08:26:19 +0000 (UTC) Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by gabe.freedesktop.org (Postfix) with ESMTPS id B99BF10E10A for ; Mon, 4 Sep 2023 08:26:17 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by madras.collabora.co.uk (Postfix) with ESMTPSA id 229C06607284; Mon, 4 Sep 2023 09:26:16 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1693815976; bh=8wUKqMOjUBu2r0rpU1ECfBJyQoIpV4aYmseq/1ioMXc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BidWVaJiSPuAy3u5EqWJTioIjOX9nkY3WWhasu1CxwbmGHwt4T1bxyAgFfyoxxan6 7Qb9+gsMdsI9YsHlZRRjqMojmiLCNnP5ZEtSBdodWnlrqWWCgaA1kxqF1RUgo/Rh1X Py5orCbxTpEvYzCJIV16IEZXqmKHiuMfW4FFRkHjc6iVpXLc1qmYGX0oL56TtO96h8 GctQkkBFgUELonuKZrc+l8+GdN2ISjBSFe0uEXqa/i4UZU4QAqvRLC6NAk+OZBjs5P /2VOOC6eIaXAz6XqVBDv52ETbSNY/VffyCXEiTvvr0lvVmwIja+iwsMXGklMdFHEIE jYRRmuqTZlsTA== Date: Mon, 4 Sep 2023 10:26:12 +0200 From: Boris Brezillon To: Steven Price Subject: Re: [PATCH v2 02/15] drm/panthor: Add uAPI Message-ID: <20230904102612.595840b1@collabora.com> In-Reply-To: References: <20230809165330.2451699-1-boris.brezillon@collabora.com> <20230809165330.2451699-3-boris.brezillon@collabora.com> <20230901181039.417c9753@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nicolas Boichat , Daniel Stone , Neil Armstrong , Liviu Dudau , dri-devel@lists.freedesktop.org, =?UTF-8?B?Q2zDqW1lbnQgUMOpcm9u?= , "Marty E . Plummer" , Robin Murphy , Faith Ekstrand Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 4 Sep 2023 08:42:08 +0100 Steven Price wrote: > On 01/09/2023 17:10, Boris Brezillon wrote: > > On Wed, 9 Aug 2023 18:53:15 +0200 > > Boris Brezillon wrote: > > > >> +/** > >> + * DOC: MMIO regions exposed to userspace. > >> + * > >> + * .. c:macro:: DRM_PANTHOR_USER_MMIO_OFFSET > >> + * > >> + * File offset for all MMIO regions being exposed to userspace. Don't use > >> + * this value directly, use DRM_PANTHOR_USER__OFFSET values instead. > >> + * > >> + * .. c:macro:: DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET > >> + * > >> + * File offset for the LATEST_FLUSH_ID register. The Userspace driver controls > >> + * GPU cache flushling through CS instructions, but the flush reduction > >> + * mechanism requires a flush_id. This flush_id could be queried with an > >> + * ioctl, but Arm provides a well-isolated register page containing only this > >> + * read-only register, so let's expose this page through a static mmap offset > >> + * and allow direct mapping of this MMIO region so we can avoid the > >> + * user <-> kernel round-trip. > >> + */ > >> +#define DRM_PANTHOR_USER_MMIO_OFFSET (0x1ull << 56) > > > > I'm playing with a 32-bit kernel/userspace, and this is problematic, > > because vm_pgoff is limited to 32-bit there, meaning we can only map up > > to (1ull << (PAGE_SHIFT + 32)) - 1. Should we add a DEV_QUERY to let > > userspace set the mmio range? > > Hmm, I was rather hoping we could ignore 32 bit these days ;) But while > I can't see why anyone would be running a 32 bit kernel, I guess 32 bit > user space is likely to still be needed. Well, I can tell you some people are using 32-bit kernels ;-). > > I can't really think of anything better than letting user space set the > MMIO range. Having an ioctl which returned a special fd just for MMIO > would be one option (which would preserve the full 44 bit GPU VA) but > seems somewhat overkill. Yeah, I don't think I like the separate-fd approach. Just feels like it goes against the DRM-way of doing things. And, with 32-bit userspace, we'd be limited by the CPU VA range anyway. Of course it's orthogonal to the max file offset, and just because we can't map all buffers at once, doesn't mean we don't want to be able to address more than 4G of memory. But with 43-bit left (I think I'd prefer if we enforce a log2 value for the mmio offset/size, meaning that the max MMIO range would be 1ull << 43), that means we're still able to address 8TB of memory. I guess that's more than enough for 32-bit users... > Hiding the mmap within an ioctl would of course > be bad as it breaks tools like Valgrind. Don't like this idea either. > > Oh and please do make it a range - user space submission will be adding > to the MMIO range ;) Yeah, that was the plan (I keep usermode submission in the back of my mind ;-)).