From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C191935966; Sun, 2 Feb 2025 18:53:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738522435; cv=none; b=VTvb9/aWEBc53XG2Igu79hD7E9hUjIM/tgafn8N/rdxT5e0KeXeN5y0IGGeVzDYZntgy6EHUgAIV+mqyJboqJRAt32jGEWkMqqQJmLka/C1xrJBs2ZaTHY6e14lTchr0d+P8Nu0+tAApmX2cuPz3rA1LzTKVuXLpHdwQuVBc5/o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738522435; c=relaxed/simple; bh=xi3bO7S2ctfq9CEqzObd0qQ5CN0JdI6OGFQ7/NUZ6oI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CJ2tZ2HS9+WZF7kJnyWynfoxxNEMdC+6dmJdf8pOWGUOoKrVvHhwTQtSHOnw4bTJ5Vw0HA8gHxEEuau5Ukcm9ca4nwPAv3JhUiiy4NlB64Lvxy85LXcsvykC8pCAuL0IAUdAE6Y8cFWEQ3PpClmP3FjbJBd0KD8gy23Zh4KKI7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TsgzfNA8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TsgzfNA8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05599C4CED1; Sun, 2 Feb 2025 18:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738522434; bh=xi3bO7S2ctfq9CEqzObd0qQ5CN0JdI6OGFQ7/NUZ6oI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TsgzfNA8ya7QtUsehA3eVGLqliTdcdpqsi4vkL+w8DTAdc+bXUSnTt6WmjOPI33wS CQ/E24ywE4WROIzdN6iXBe/XDLYA4MF9TdgWXBw7x5EuLKyFbEKrAmECF4DC9Ksbvu xwuBhhH1dZNy9pfm3Q9Q75+Piz2XovVofQ4j+CZ7rZwCzqVSGih1Ld43g2Kkb66Kl7 fl/R3ohwjrWeSdP6gzzT1Lho6rSISTlEn0vrv25RZ1iGfAVZbBbhsmFibx5vmglCWX 94oisaMm+MKCTDnrNnksaREROgXxhjDf+YhDd6yBhgk7UjLcGgRoezBg2VYrMVbbBS /ZkCdT5OHR+zQ== Date: Sun, 2 Feb 2025 19:53:47 +0100 From: Danilo Krummrich To: Asahi Lina Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Frank Binns , Matt Coster , Karol Herbst , Lyude Paul , Boris Brezillon , Steven Price , Liviu Dudau , Lucas De Marchi , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , Rodrigo Vivi , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, intel-xe@lists.freedesktop.org, asahi@lists.linux.dev Subject: Re: [PATCH 0/4] drm/gpuvm: Add support for single-page-filled mappings Message-ID: References: <20250202-gpuvm-single-page-v1-0-8cbd44fdcbd4@asahilina.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250202-gpuvm-single-page-v1-0-8cbd44fdcbd4@asahilina.net> Hi Lina, On Sun, Feb 02, 2025 at 10:34:49PM +0900, Asahi Lina wrote: > Some hardware requires dummy page mappings to efficiently implement > Vulkan sparse features. These mappings consist of the same physical > memory page, repeated for a large range of address space (e.g. 16GiB). > > Add support for this to drm_gpuvm. Currently, drm_gpuvm expects BO > ranges to correspond 1:1 to virtual memory ranges that are mapped, and > does math on the BO offset accordingly. To make single page mappings > work, we need a way to turn off that math, keeping the BO offset always > constant and pointing to the same page (typically BO offset 0). > > To make this work, we need to handle all the corner cases when these > mappings intersect with regular mappings. The rules are simply to never > mix or merge a "regular" mapping with a single page mapping. > > drm_gpuvm has support for a flags field in drm_gpuva objects. This is > normally managed by drivers directly. We can introduce a > DRM_GPUVA_SINGLE_PAGE flag to handle this. However, to make it work, > sm_map and friends need to know ahead of time whether the new mapping is > a single page mapping or not. Therefore, we need to add an argument to > these functions so drivers can provide the flags to be filled into > drm_gpuva.flags. > > These changes should not affect any existing drivers that use drm_gpuvm > other than the API change: > > - imagination: Does not use flags at all > - nouveau: Only uses drm_gpuva_invalidate(), which is only called on > existing drm_gpuva objects (after the map steps) > - panthor: Does not use flags at all > - xe: Does not use drm_gpuva_init_from_op() or > drm_gpuva_remap()/drm_gpuva_map() (which call it). This means that the > flags field of the gpuva object is managed by the driver only, so these > changes cannot clobber it. > > Note that the way this is implemented, drm_gpuvm does not need to know > the GPU page size. It only has to never do math on the BO offset to meet > the requirements. > > I suspect that after this change there could be some cleanup possible in > the xe driver (which right now passes flags around in various > driver-specific ways from the map step through to drm_gpuva objects), > but I'll leave that to the Xe folks. > > Signed-off-by: Asahi Lina > --- > Asahi Lina (4): > drm/gpuvm: Add a flags argument to drm_gpuvm_sm_map[_*] > drm/gpuvm: Plumb through flags into drm_gpuva_op_map > drm/gpuvm: Add DRM_GPUVA_SINGLE_PAGE flag and logic > drm/gpuvm: Plumb through flags into drm_gpuva_init Without looking into any details yet: This is a bit of tricky one, since we're not even close to having a user for this new feature upstream yet, are we? I wonder if we could do an exception by adding some KUnit tests (which admittedly I never got to) validating things with and without this new feature. Speaking of tests, how did you validate this change to validate the behavior without DRM_GPUVA_SINGLE_PAGE? - Danilo