[PATCH] drm/msm: align kernel-managed GPU VAs to 64 KiB

[PATCH] drm/msm: align kernel-managed GPU VAs to 64 KiB

[Gaurav Suman]

On an Adreno 640 (SM8150, LG G8x) GNOME Shell triggers SMMU
translation faults with source=CCU, about ten per login, when
freedreno uses GMEM (binning) rendering. FD_MESA_DEBUG=nogmem or
=inorder hides them.

A stall-on-fault capture decoded with crashdec shows the faulting
address at an exact 64 KiB boundary (FAR 0x110690000) while the pass
drew to MRT0 at 0x110695000 and depth at 0x11069f000, all in that
64 KiB block. The block start belonged to the unmapped tail of
another buffer that was not part of the running submit. A ring
buffer of pagetable operations confirmed this for every fault: the
CCU reads the 64 KiB-aligned start of the block holding a bound
render target, and msm packs kernel-managed VAs at 4 KiB, so that
address often belongs to a different, unmapped buffer. Batch
reordering makes this common, which is why inorder hides it.

Align kernel-managed VAs to 64 KiB, falling back to page alignment
when the range is too tight (a6xx_gmu_init() fails with -ENOSPC
otherwise).

Tested on the LG G8x with Mesa unchanged and GMEM enabled: in an A/B
run in one boot, 4 KiB alignment gave 10 and 10 faults per login, 64
KiB alignment 0, 0, 0 and 0. No faults in three further logins, a
GMEM stress test or the full device test suite; glmark2 is unchanged
within noise. Userspace-managed VMs (VM_BIND) are not changed; Mesa
may want the same alignment there.

This was investigated, written and tested with the help of an AI
coding assistant (Claude Opus 5.5, Anthropic); I reviewed the change
and the test results.

Signed-off-by: Gaurav Suman <gauravsuman007@gmail.com>
---
Tested on LG G8x ThinQ (SM8150).
---
 drivers/gpu/drm/msm/msm_gem_vma.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
index f687a629629d348b54ebb379d3a2fa956b8e472e..2af43291289945d54326287affeffa7e72645880 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -388,9 +388,20 @@ msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
 	if (vm->managed) {
 		BUG_ON(offset != 0);
 		BUG_ON(!obj);  /* NULL mappings not valid for kernel managed VM */
+		/*
+		 * On a6xx (seen on A640) the CCU can read the 64 KiB-aligned
+		 * start of the block that holds a bound render target. Align
+		 * kernel-managed VAs to 64 KiB so that block start lies inside
+		 * the buffer itself; callers with a tight fixed window, such as
+		 * the GMU, fall back to page alignment.
+		 */
 		ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
-						obj->size, PAGE_SIZE, 0,
+						obj->size, SZ_64K, 0,
 						range_start, range_end, 0);
+		if (ret == -ENOSPC)
+			ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
+							  obj->size, PAGE_SIZE, 0,
+							  range_start, range_end, 0);
 
 		if (ret)
 			goto err_free_vma;

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
change-id: 20261109-msm-va-align-072b585038aa

Best regards,
-- 
Gaurav Suman <gauravsuman007@gmail.com>

[PATCH] drm/msm: align kernel-managed GPU VAs to 64 KiB

[Gaurav Suman via B4 Relay]

From: Gaurav Suman <gauravsuman007@gmail.com>

On an Adreno 640 (SM8150, LG G8x) GNOME Shell triggers SMMU
translation faults with source=CCU, about ten per login, when
freedreno uses GMEM (binning) rendering. FD_MESA_DEBUG=nogmem or
=inorder hides them.

A stall-on-fault capture decoded with crashdec shows the faulting
address at an exact 64 KiB boundary (FAR 0x110690000) while the pass
drew to MRT0 at 0x110695000 and depth at 0x11069f000, all in that
64 KiB block. The block start belonged to the unmapped tail of
another buffer that was not part of the running submit. A ring
buffer of pagetable operations confirmed this for every fault: the
CCU reads the 64 KiB-aligned start of the block holding a bound
render target, and msm packs kernel-managed VAs at 4 KiB, so that
address often belongs to a different, unmapped buffer. Batch
reordering makes this common, which is why inorder hides it.

Align kernel-managed VAs to 64 KiB, falling back to page alignment
when the range is too tight (a6xx_gmu_init() fails with -ENOSPC
otherwise).

Tested on the LG G8x with Mesa unchanged and GMEM enabled: in an A/B
run in one boot, 4 KiB alignment gave 10 and 10 faults per login, 64
KiB alignment 0, 0, 0 and 0. No faults in three further logins, a
GMEM stress test or the full device test suite; glmark2 is unchanged
within noise. Userspace-managed VMs (VM_BIND) are not changed; Mesa
may want the same alignment there.

This was investigated, written and tested with the help of an AI
coding assistant (Claude Opus 5.5, Anthropic); I reviewed the change
and the test results.

Signed-off-by: Gaurav Suman <gauravsuman007@gmail.com>
---
Tested on LG G8x ThinQ (SM8150).
---
 drivers/gpu/drm/msm/msm_gem_vma.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
index f687a629629d348b54ebb379d3a2fa956b8e472e..2af43291289945d54326287affeffa7e72645880 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -388,9 +388,20 @@ msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
 	if (vm->managed) {
 		BUG_ON(offset != 0);
 		BUG_ON(!obj);  /* NULL mappings not valid for kernel managed VM */
+		/*
+		 * On a6xx (seen on A640) the CCU can read the 64 KiB-aligned
+		 * start of the block that holds a bound render target. Align
+		 * kernel-managed VAs to 64 KiB so that block start lies inside
+		 * the buffer itself; callers with a tight fixed window, such as
+		 * the GMU, fall back to page alignment.
+		 */
 		ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
-						obj->size, PAGE_SIZE, 0,
+						obj->size, SZ_64K, 0,
 						range_start, range_end, 0);
+		if (ret == -ENOSPC)
+			ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
+							  obj->size, PAGE_SIZE, 0,
+							  range_start, range_end, 0);
 
 		if (ret)
 			goto err_free_vma;

---
base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
change-id: 20261109-msm-va-align-072b585038aa

Best regards,
-- 
Gaurav Suman <gauravsuman007@gmail.com>

Re: [PATCH] drm/msm: align kernel-managed GPU VAs to 64 KiB

[Rob Clark]

On Mon, Nov 9, 2026 at 2:34 PM Gaurav Suman via B4 Relay
<devnull+gauravsuman007.gmail.com@kernel.org> wrote:
>
> From: Gaurav Suman <gauravsuman007@gmail.com>
>
> On an Adreno 640 (SM8150, LG G8x) GNOME Shell triggers SMMU
> translation faults with source=CCU, about ten per login, when
> freedreno uses GMEM (binning) rendering. FD_MESA_DEBUG=nogmem or
> =inorder hides them.
>
> A stall-on-fault capture decoded with crashdec shows the faulting
> address at an exact 64 KiB boundary (FAR 0x110690000) while the pass
> drew to MRT0 at 0x110695000 and depth at 0x11069f000, all in that
> 64 KiB block. The block start belonged to the unmapped tail of
> another buffer that was not part of the running submit. A ring
> buffer of pagetable operations confirmed this for every fault: the
> CCU reads the 64 KiB-aligned start of the block holding a bound
> render target, and msm packs kernel-managed VAs at 4 KiB, so that
> address often belongs to a different, unmapped buffer. Batch
> reordering makes this common, which is why inorder hides it.
>
> Align kernel-managed VAs to 64 KiB, falling back to page alignment
> when the range is too tight (a6xx_gmu_init() fails with -ENOSPC
> otherwise).
>
> Tested on the LG G8x with Mesa unchanged and GMEM enabled: in an A/B
> run in one boot, 4 KiB alignment gave 10 and 10 faults per login, 64
> KiB alignment 0, 0, 0 and 0. No faults in three further logins, a
> GMEM stress test or the full device test suite; glmark2 is unchanged
> within noise. Userspace-managed VMs (VM_BIND) are not changed; Mesa
> may want the same alignment there.

This seems like it is papering over a userspace bug..

Could you file a bug on mesa gitlab[1] and attach a GPU devcoredump[2]
after an SMMU fault?

BR,
-R

[1] https://gitlab.freedesktop.org/mesa/mesa/-/work_items
[2] https://docs.mesa3d.org/drivers/freedreno.html#gpu-devcoredump

> This was investigated, written and tested with the help of an AI
> coding assistant (Claude Opus 5.5, Anthropic); I reviewed the change
> and the test results.
>
> Signed-off-by: Gaurav Suman <gauravsuman007@gmail.com>
> ---
> Tested on LG G8x ThinQ (SM8150).
> ---
>  drivers/gpu/drm/msm/msm_gem_vma.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
> index f687a629629d348b54ebb379d3a2fa956b8e472e..2af43291289945d54326287affeffa7e72645880 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -388,9 +388,20 @@ msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
>         if (vm->managed) {
>                 BUG_ON(offset != 0);
>                 BUG_ON(!obj);  /* NULL mappings not valid for kernel managed VM */
> +               /*
> +                * On a6xx (seen on A640) the CCU can read the 64 KiB-aligned
> +                * start of the block that holds a bound render target. Align
> +                * kernel-managed VAs to 64 KiB so that block start lies inside
> +                * the buffer itself; callers with a tight fixed window, such as
> +                * the GMU, fall back to page alignment.
> +                */
>                 ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
> -                                               obj->size, PAGE_SIZE, 0,
> +                                               obj->size, SZ_64K, 0,
>                                                 range_start, range_end, 0);
> +               if (ret == -ENOSPC)
> +                       ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
> +                                                         obj->size, PAGE_SIZE, 0,
> +                                                         range_start, range_end, 0);
>
>                 if (ret)
>                         goto err_free_vma;
>
> ---
> base-commit: ddfe51b0a0f5dc9e415cc2c8ad8db17532dd426b
> change-id: 20261109-msm-va-align-072b585038aa
>
> Best regards,
> --
> Gaurav Suman <gauravsuman007@gmail.com>
>
>

Re: [PATCH] drm/msm: align kernel-managed GPU VAs to 64 KiB

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/msm: sub-64K hole scan and VA fragmentation in
  msm_gem_vma_new()
--

commit dbbe11968537b24a2b140215f7ad31d5a022afb3
Author: Gaurav Suman <gauravsuman007@gmail.com>

drm/msm: align kernel-managed GPU VAs to 64 KiB

This commit aligns virtual address allocations in kernel-managed GPU VMs to
64 KiB in msm_gem_vma_new(), falling back to PAGE_SIZE alignment on -ENOSPC.

> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
> index f687a629629d3..2af4329128994 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -388,9 +388,20 @@ msm_gem_vma_new(struct drm_gpuvm *gpuvm, struct drm_gem_object *obj,
>  	if (vm->managed) {
>  		BUG_ON(offset != 0);
>  		BUG_ON(!obj);  /* NULL mappings not valid for kernel managed VM */
> +		/*
> +		 * On a6xx (seen on A640) the CCU can read the 64 KiB-aligned
> +		 * start of the block that holds a bound render target. Align
> +		 * kernel-managed VAs to 64 KiB so that block start lies inside
> +		 * the buffer itself; callers with a tight fixed window, such as
> +		 * the GMU, fall back to page alignment.
> +		 */
>  		ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
> -						obj->size, PAGE_SIZE, 0,
> +						obj->size, SZ_64K, 0,
>  						range_start, range_end, 0);
> +		if (ret == -ENOSPC)
> +			ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
> +							  obj->size, PAGE_SIZE, 0,
> +							  range_start, range_end, 0);

[Severity: Medium]
Does aligning vma->node to SZ_64K while keeping obj->size page-aligned
degrade small BO allocations in vm->mm to an O(N) hole scan and fragment
small kernel-managed VMs?

When obj->size is not a multiple of 64 KiB (such as a 4 KiB BO), rounding
the next allocation up to a 64 KiB boundary in drm_mm_insert_node_in_range()
leaves an unaligned gap of up to 60 KiB in vm->mm.holes_size that contains
no 64 KiB-aligned address.  Because mode 0 (DRM_MM_INSERT_BEST) starts at
the smallest hole >= obj->size and steps through vm->mm.holes_size in
non-decreasing size order, every subsequent SZ_64K-aligned allocation of a
small BO walks past all accumulated sub-64 KiB holes before reaching a
usable hole.

This also applies to all kernel-managed VMs rather than just a6xx: in
a2xx_create_vm(), the GPU VM is only 0xfff * SZ_64K (~256 MiB), so 4095
4 KiB BOs fragment the entire address space into 60 KiB holes and cause any
subsequent allocation of size >= 64 KiB to fail with -ENOSPC even with the
PAGE_SIZE fallback.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-msm-va-align-v1-1-2e9b576d2e4e@gmail.com?part=1