From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 AF4FB3290D5 for ; Wed, 20 May 2026 06:16:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779257777; cv=none; b=SU3fYR2KdKHKcYDtGMIuEWzrRUO39y7FEC9evBsidSqowiS9+HGsuO4PSlzGO4cMTto7doDn3LbbCiyuHa8kPvKjFSlaXW4QwHpDWZUoraCSnCKKBE8a+q7ursHUVYIZx4LHcMwwadu4hJhvxy5OZxZpswN9B7ENNaMbmXaRM7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779257777; c=relaxed/simple; bh=QhEY74D9z4Dh/emvIJ/nWeCVZgPpAM04f+LEhYim0kg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WglsfJpY+lZS81vKBOlLhqykHpEHfrVlLltd0/n+Hqi1W3JrhcufdzwGaXTMB2CrK3WzMgCNlZxVdYJBY/zxbvZdz1NTdzir7bEaXPAzl4Ad72bQokdwlw+rlu9PF6nT7Hiy581q/NPOQbcvuK36ngygMMN/UPAFpYInjdL835Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=NU6Za/ei; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="NU6Za/ei" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1779257773; bh=QhEY74D9z4Dh/emvIJ/nWeCVZgPpAM04f+LEhYim0kg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NU6Za/eiRsHxH6sVx6Ztni8rRtqDN7h2+nczjYiymndMyTl46cMc6hDtYQtQBFWZr TPfTBYkDajWWAmK5I30vP+CTNoDgAwl4fwmv4jgkf/qTK2CbmBcKuSzf90xtPkZVbi WBPDVCNye92JZbhfP9c7G3iGI9r5z7dnpiJ8AP96YqbnUidARDSl7aGd9HK9sEYqa0 rkxkUwhQUEAphGWGbSFEkd6/mthw9RMVXYSV6cFoQvWOdG+OQDKA8BCLkrVZWbOf7o MoyOCZl5jBSt7/pEB9hVPpk4pQ7o0NFUp3ZIrcfazJ3SvrBcf84GxN003br2cZAAVC w0XWpxzfH5/fg== Received: from fedora (unknown [100.64.0.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 5A91B17E05B5; Wed, 20 May 2026 08:16:13 +0200 (CEST) Date: Wed, 20 May 2026 08:16:08 +0200 From: Boris Brezillon To: =?UTF-8?B?QWRyacOhbg==?= Larumbe Cc: Steven Price , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kernel@collabora.com, Liviu Dudau , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Daniel Almeida , Alice Ryhl Subject: Re: [PATCH v11 5/6] drm/panthor: Support sparse mappings Message-ID: <20260520081608.0122a1d4@fedora> In-Reply-To: References: <20260507214939.2852489-1-adrian.larumbe@collabora.com> <20260507214939.2852489-6-adrian.larumbe@collabora.com> <661a6aab-a643-496b-94d2-ae9230df1a54@arm.com> Organization: Collabora X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 19 May 2026 20:15:34 +0100 Adri=C3=A1n Larumbe wrote: > Hi Steven, >=20 > On 13.05.2026 16:46, Steven Price wrote: > > On 07/05/2026 22:49, Adri=C3=A1n Larumbe wrote: =20 > > > Allow UM to bind sparsely populated memory regions by cyclically mapp= ing > > > virtual ranges over a kernel-allocated dummy BO. This alternative is > > > preferable to the old method of handling sparseness in the UMD, becau= se it > > > relied on the creation of a buffer object to the same end, despite th= e fact > > > Vulkan sparse resources don't need to be backed by a driver BO. > > > > > > The choice of backing sparsely-bound regions with a Panthor BO was ma= de so > > > as to profit from the existing shrinker reclaim code. That way no spe= cial > > > treatment must be given to the dummy sparse BOs when reclaiming memor= y, as > > > would be the case if we had chosen a raw kernel page implementation. = =20 > > > > Do you need to fix up the remap_evicted_vma() path though? At the moment > > that will go through panthor_vm_map_pages() without doing the > > panthor_fix_sparse_map_offset() dance. Also I suspect it won't map the > > whole region (just the first 2MB in the sgtable). =20 >=20 > You're right, we need to account for the case in which the VMA is of the = sparse kind > and backed by the dummy BO. I suggest something as follows: >=20 > ``` diff > ret =3D panthor_vm_lock_region(vm, evicted_vma->base.va.addr, > evicted_vma->base.va.range); > if (!ret) { > - ret =3D panthor_vm_map_pages(vm, evicted_vma->base.va.addr, > - flags_to_prot(evicted_vma->flags), > - bo->dmap.sgt, > - evicted_vma->base.gem.offset, > - evicted_vma->base.va.range); > + struct drm_gpuva_op_map map_op =3D { > + .va.addr =3D evicted_vma->base.va.addr, > + .va.range =3D evicted_vma->base.va.range, > + .gem.obj =3D &bo->base, > + .gem.offset =3D evicted_vma->base.gem.offset, > + }; > + if (evicted_vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE) > + drm_WARN_ON(&vm->ptdev->base, map_op.gem.offset !=3D > + (map_op.va.addr & (SZ_2M - 1))); > + > + ret =3D panthor_vm_exec_map_op(vm, evicted_vma->flags, &map_op); > if (!ret) > evicted_vma->evicted =3D false; > ``` >=20 > However, it seems to me there's no need for panthor_fix_sparse_map_offset= () in this code path, > because a VMA should always have the right gem offset even after eviction= . This holds true in > the event of an sm_remap of a VMA that had already been evicted. Yep, I think you're right. >=20 > This led me to think doing a WARN_ON test on the offset is the right way = to go. A WARN_ON[_ONCE]() would do, yes.