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 DFE213976B4 for ; Thu, 26 Mar 2026 23:18:11 +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=1774567091; cv=none; b=tdFAopY6dB1tKbTuUGSVWQEbb9/J4zAaYUzBPo+pqZ7bRUiAaGK2FKwxlA02heF+7aUTDdqFa1xiBvNsB2BfK1Qw93TTyReip5F+S3d4a8VekloN4NRzwov/+s3PORfR9U3BkbMvgKHrFellSsMNUjOqsv9cSIPrGpxuod0yP3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774567091; c=relaxed/simple; bh=UmIsA1Hp8/Hqt5C7CdY95JzKtszZD0igX6Ar7eTPMHM=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=R+lT+lym4fjqIyuQLy/NWMlQkIVPZMpHsj7opnhstAun9GUuAe7pGZlfvj7b0glj5DdPtO9Lb9/7UCBydjMULJeiLiGxe6THdpr/wy+e4UhR3KUHvckQIZQvak8efn5gsiEXug98dDtpiELbWk8W6qtAvdWRC/Jxs/8F/3Nm0a8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SExRwnYV; 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="SExRwnYV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58A22C116C6; Thu, 26 Mar 2026 23:18:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774567091; bh=UmIsA1Hp8/Hqt5C7CdY95JzKtszZD0igX6Ar7eTPMHM=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=SExRwnYVKoPF3hQ7zlSdsGgq6dYMvN+Wyoa3S1kU6uFxcF6Y8HwNQmjq7/0sT/2MY iT5BjKYa4zN9JrnuXx3N61lTWWNWfTY+xJDk490WS9XFpurxlLR+brm1bYA0Ej/GLO YWV3DjOvZFwFq0hz/B3hpUJIZfsSShvbBw22vy6170lyYmlZeh/FzG4C4+FItQcNdg fbi5LQzOMZ81dyheuXDr/vj+q4qydPc2ygObYac7LmsM6ITXRUNYyPd9i6Nag66hJH cGngck+wG74Fx2UW3AsARA+eRlJaPYcb9COcOT3VzCLizNMiOu5VdJyM0UvZY3qrek IvkbPo7tT3b9w== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 27 Mar 2026 00:18:06 +0100 Message-Id: Subject: Re: [PATCH v5 06/11] drm/gpuvm: Add DRM_GPUVA_REPEAT flag and logic Cc: , , "Steven Price" , "Boris Brezillon" , "Janne Grunau" , , "Asahi Lina" , "Caterina Shablia" , "Matthew Brost" , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , "Alice Ryhl" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" To: =?utf-8?q?Adri=C3=A1n_Larumbe?= From: "Danilo Krummrich" References: <20260313150956.1618635-1-adrian.larumbe@collabora.com> <20260313150956.1618635-7-adrian.larumbe@collabora.com> In-Reply-To: <20260313150956.1618635-7-adrian.larumbe@collabora.com> On Fri Mar 13, 2026 at 4:09 PM CET, Adri=C3=A1n Larumbe wrote: > From: Asahi Lina > > To be able to support "fake sparse" mappings without relying on GPU page > fault handling, drivers may need to create large (e.g. 4GiB) mappings of > the same page repeatedly (or same range of pages). Doing this through > individual mappings would be very wasteful. This can be handled better > by using a flag on map creation, but to do it safely, drm_gpuvm needs to > be aware of this special case. > > Add a flag that signals that a given mapping is a page mapping, which is > repeated all over the entire requested VA range. This tweaks the > sm_map() logic to treat the GEM offsets differently when mappings are > a repeated ones so they are not incremented as they would be with regular > mappings. > > The size of the GEM portion to repeat is passed through > drm_gpuva::gem::range. Most of the time it will be a page size, but > it can be bigger as long as it's less than drm_gpuva::va::range, and > drm_gpuva::va::range is a multiple of drm_gpuva::gem::range. > > Signed-off-by: Asahi Lina > Signed-off-by: Caterina Shablia In v4 I also mentioned: I also think this feature deserves its own section in the global GPUVM documentation -- please add a corresponding paragraph. Also it seems that we need to update the documentation which shows all pot= ential cases when calling __drm_gpuvm_sm_map() [1]. [1] https://docs.kernel.org/gpu/drm-mm.html#split-and-merge Why did this not happen? > +static int validate_map_request(struct drm_gpuvm *gpuvm, > + const struct drm_gpuva_op_map *op) > +{ > + if (unlikely(!drm_gpuvm_range_valid(gpuvm, op->va.addr, op->va.range))) > + return -EINVAL; > + > + if (op->flags & DRM_GPUVA_REPEAT) { > + u64 va_range =3D op->va.range; > + > + /* For a repeated mapping, GEM range must be > 0 > + * and a multiple of the VA range. > + */ > + if (unlikely(!op->gem.repeat_range || > + va_range < op->gem.repeat_range || > + do_div(va_range, op->gem.repeat_range))) > + return -EINVAL; > + } > + > + if (op->flags & DRM_GPUVA_INVALIDATED) > + return -EINVAL; This seems unrelated to this patch. > + > + return 0; > +} > + > static int > __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm, > const struct drm_gpuvm_ops *ops, void *priv, > @@ -2429,7 +2475,8 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm, > u64 req_end =3D req_addr + req_range; > int ret; > =20 > - if (unlikely(!drm_gpuvm_range_valid(gpuvm, req_addr, req_range))) > + ret =3D validate_map_request(gpuvm, &req->map); > + if (unlikely(ret)) > return -EINVAL; > =20 > drm_gpuvm_for_each_va_range_safe(va, next, gpuvm, req_addr, req_end) { > @@ -2463,7 +2510,9 @@ __drm_gpuvm_sm_map(struct drm_gpuvm *gpuvm, > .va.addr =3D req_end, > .va.range =3D range - req_range, > .gem.obj =3D obj, > - .gem.offset =3D offset + req_range, > + .gem.repeat_range =3D va->gem.repeat_range, > + .gem.offset =3D offset + > + (va->flags & DRM_GPUVA_REPEAT ? 0 : req_range), This seems to be a repeating pattern, can we factor this into a helper?