From: sashiko-bot@kernel.org
To: "Zhigang Luo" <Zhigang.Luo@amd.com>, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/7] drm/amdgpu: fill the A+A VF PDB0 through get_vm_pde
Date: Fri, 13 Nov 2026 15:14:17 +0000 [thread overview]
Message-ID: <sashiko-outbox-213068@kernel.org> (raw)
In-Reply-To: <20261113145702.323968-5-Zhigang.Luo@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/amdgpu: amdgpu_gmc_init_pdb0() corrupts GFX9 PDB0 via
get_vm_pde()
--
commit 94fec17ddae148fbc91f8d2688eb078363097ddd
Author: Zhigang Luo <Zhigang.Luo@amd.com>
drm/amdgpu: fill the A+A VF PDB0 through get_vm_pde
This commit routes the VRAM PDE_PTE entries and the GART PTB PDE0 entry in
amdgpu_gmc_init_pdb0() through amdgpu_gmc_get_vm_pde().
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 659e89e5e78f1..04cf02dd22acb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -1272,7 +1272,7 @@ void amdgpu_gmc_init_pdb0(struct amdgpu_device *adev)
> u64 vram_size = adev->gmc.xgmi.node_segment_size * adev->gmc.xgmi.num_physical_nodes;
> u64 pde0_page_size = (1ULL<<adev->gmc.vmid0_page_table_block_size)<<21;
> u64 vram_addr, vram_end;
> - u64 gart_ptb_gpu_pa = amdgpu_gmc_vram_pa(adev, adev->gart.bo);
> + u64 pde_addr, pde_flags;
> int idx;
>
> if (!drm_dev_enter(adev_to_drm(adev), &idx))
> @@ -1290,10 +1290,16 @@ void amdgpu_gmc_init_pdb0(struct amdgpu_device *adev)
> vram_end = vram_addr + vram_size;
>
> /* The first n PDE0 entries are used as PTE,
> - * pointing to vram
> + * pointing to vram. PDE_PTE already holds a physical address, so
> + * get_vm_pde() skips translation and sets S for SPM.
> */
> - for (i = 0; vram_addr < vram_end; i++, vram_addr += pde0_page_size)
> - amdgpu_gmc_set_pte_pde(adev, adev->gmc.ptr_pdb0, i, vram_addr, flags);
> + for (i = 0; vram_addr < vram_end; i++, vram_addr += pde0_page_size) {
> + pde_addr = vram_addr;
> + pde_flags = flags;
> + amdgpu_gmc_get_vm_pde(adev, AMDGPU_VM_PDB0, &pde_addr, &pde_flags);
> + amdgpu_gmc_set_pte_pde(adev, adev->gmc.ptr_pdb0, i, pde_addr,
> + pde_flags);
> + }
>
> /* The n+1'th PDE0 entry points to a huge
> * PTB who has more than 512 entries each
> @@ -1301,8 +1307,12 @@ void amdgpu_gmc_init_pdb0(struct amdgpu_device *adev)
> */
> flags = AMDGPU_PTE_VALID;
> flags |= AMDGPU_PTE_SNOOPED | AMDGPU_PDE_BFS_FLAG(adev, 0);
> - /* Requires gart_ptb_gpu_pa to be 4K aligned */
> - amdgpu_gmc_set_pte_pde(adev, adev->gmc.ptr_pdb0, i, gart_ptb_gpu_pa, flags);
> + /* MC address. get_vm_pde() translates it once and sets S for SPM.
> + * Requires the GART PT to be 4K aligned.
> + */
> + pde_addr = amdgpu_bo_gpu_offset(adev->gart.bo);
> + amdgpu_gmc_get_vm_pde(adev, AMDGPU_VM_PDB0, &pde_addr, &flags);
> + amdgpu_gmc_set_pte_pde(adev, adev->gmc.ptr_pdb0, i, pde_addr, flags);
[Severity: High]
Does passing AMDGPU_VM_PDB0 to amdgpu_gmc_get_vm_pde() corrupt the VMID0
PDB0 table on GFX9 devices?
amdgpu_gmc_init_pdb0() is also called from gmc_v9_0_gart_enable() on GFX9
ASICs with PDB0 enabled (such as Aldebaran and Aqua Vanjaram), where
adev->gmc.translate_further is true for 4-level user VMs:
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:gmc_v9_0_get_vm_pde() {
...
if (!adev->gmc.translate_further)
return;
if (level == AMDGPU_VM_PDB1) {
...
} else if (level == AMDGPU_VM_PDB0) {
if (*flags & AMDGPU_PDE_PTE) {
*flags &= ~AMDGPU_PDE_PTE;
if (!(*flags & AMDGPU_PTE_VALID))
*addr |= 1 << PAGE_SHIFT;
} else {
*flags |= AMDGPU_PTE_TF;
}
}
}
Unlike VM_CONTEXT1..15, VM_CONTEXT0_CNTL.PAGE_TABLE_DEPTH is programmed to
vmid0_page_table_depth (1) without subtracting 1 for translate_further.
Clearing AMDGPU_PDE_PTE on the VRAM entries causes the hardware walker to
treat each VRAM physical address as a child PTB pointer instead of a leaf
PTE, and setting AMDGPU_PTE_TF on the GART entry sets a PTE-only bit in a
depth-1 PDE0 entry, breaking system-domain VRAM and GART translation on
GFX9.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113145702.323968-1-Zhigang.Luo@amd.com?part=5
next prev parent reply other threads:[~2026-11-13 15:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 14:56 [PATCH 1/7] Revert "drm/amdgpu: mark A+A VF VRAM mappings as system memory" Zhigang Luo
2026-11-13 14:56 ` [PATCH 2/7] Revert "drm/amdkfd: mark A+A VF VRAM PTEs " Zhigang Luo
2026-11-13 15:16 ` sashiko-bot
2026-11-13 14:56 ` [PATCH 3/7] Revert "drm/amdgpu: take the A+A VF GMC aperture from SRAT" Zhigang Luo
2026-11-13 15:20 ` sashiko-bot
2026-11-13 14:56 ` [PATCH 4/7] drm/amdgpu: set the A+A VF SYSTEM bit in the GFX 12.1 helpers Zhigang Luo
2026-11-13 15:20 ` sashiko-bot
2026-11-13 14:57 ` [PATCH 5/7] drm/amdgpu: fill the A+A VF PDB0 through get_vm_pde Zhigang Luo
2026-11-13 15:14 ` sashiko-bot [this message]
2026-11-13 14:57 ` [PATCH 6/7] drm/amdgpu: align the sysvm GART start to 8GB Zhigang Luo
2026-11-13 15:05 ` sashiko-bot
2026-11-13 14:57 ` [PATCH 7/7] drm/amdgpu: keep the A+A VF VRAM base at the SRAT address Zhigang Luo
2026-11-13 15:29 ` sashiko-bot
2026-11-13 15:11 ` [PATCH 1/7] Revert "drm/amdgpu: mark A+A VF VRAM mappings as system memory" sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-213068@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Zhigang.Luo@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.