public inbox for amd-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Timur Kristóf" <timur.kristof@gmail.com>
To: amd-gfx@lists.freedesktop.org, alexander.deucher@amd.com,
	"John Olender" <john.olender@gmail.com>,
	"Liu, Leo" <Leo.Liu@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH 11/11] drm/amdgpu/vce4: Fix VCE 4 firmware size and offsets
Date: Thu, 23 Apr 2026 13:50:11 +0200	[thread overview]
Message-ID: <2603876.XAFRqVoOGU@timur-hyperion> (raw)
In-Reply-To: <4d9390ee-cfc3-42cb-bee3-df6b9539078b@amd.com>

On Thursday, April 23, 2026 1:31:03 PM Central European Summer Time Christian 
König wrote:
> On 4/23/26 03:16, Timur Kristóf wrote:
> > The VCPU BO contains the actual FW at an offset, but
> > it was not calculated into the VCPU BO size.
> > Subtract this from the FW size to make sure there is
> > no out of bounds access.
> > 
> > This may fix VM faults when using VCE 4.
> > 
> > Cc: John Olender <john.olender@gmail.com>
> > Fixes: c1dc356a116c ("drm/amdgpu: add initial vce 4.0 support for vega10")
> > Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
> 
> Leo can you take a look at this? VCE4 doesn't use the classic VCE FW
> validation any more.
> 
> So I'm not sure we have nor need that here.
> 
> Regards,
> Christian.

Hi  Leo & Christian,

If you take a look at vce_v4_0_mc_resume() you can see that it initializes the 
firmware offset like this:

offset = AMDGPU_VCE_FIRMWARE_OFFSET;

Specifically for the non-PSP code path, this triggers exactly the same issue as 
VCE2-3, that this causes the STACK and DATA to be also offset, and hence the 
DATA will be out of bounds of the VCPU BO.

For the PSP code path, the STACK and DATA no longer depend on the firmware 
offset and size, so that is fortunately not an issue anymore. In that case 
however the driver still uses the same offset for the ucode.

Best regards,
Timur

> 
> > ---
> > 
> >  drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c index
> > 3309e7b8f2a2e..eaa3e05a52e59 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> > @@ -281,7 +281,7 @@ static int vce_v4_0_sriov_start(struct amdgpu_device
> > *adev)> 
> >  						
mmVCE_LMI_VCPU_CACHE_64BIT_BAR2),
> >  						(adev-
>vce.gpu_addr >> 40) & 0xff);
> > 
> > -		size = VCE_V4_0_FW_SIZE;
> > +		size = VCE_V4_0_FW_SIZE - AMDGPU_VCE_FIRMWARE_OFFSET;
> > 
> >  		MMSCH_V1_0_INSERT_DIRECT_WT(SOC15_REG_OFFSET(VCE, 0,
> >  		mmVCE_VCPU_CACHE_SIZE0), size);
> >  		
> >  		offset = (adev->firmware.load_type != AMDGPU_FW_LOAD_PSP) 
? offset +
> >  		size : 0;





      reply	other threads:[~2026-04-23 11:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23  1:16 [PATCH 00/11] VCE1 fixes (v2) Timur Kristóf
2026-04-23  1:16 ` [PATCH 01/11] drm/amdgpu: Align amdgpu_gtt_mgr entries to TLB size on Tahiti Timur Kristóf
2026-04-23 11:04   ` Christian König
2026-04-23 12:18     ` Timur Kristóf
2026-04-23 13:32       ` Christian König
2026-04-23  1:16 ` [PATCH 02/11] drm/amdgpu/vce1: Check that the GPU address is < 128 MiB Timur Kristóf
2026-04-23 11:06   ` Christian König
2026-04-23  1:16 ` [PATCH 03/11] drm/amdgpu/vce1: Remove superfluous address check Timur Kristóf
2026-04-23  1:16 ` [PATCH 04/11] drm/amdgpu/vce1: Check if VRAM address is lower than GART Timur Kristóf
2026-04-23  1:16 ` [PATCH 05/11] drm/amdgpu/vce1: Don't repeat GTT MGR node allocation Timur Kristóf
2026-04-23  1:16 ` [PATCH 06/11] drm/amdgpu/vce1: Fix VCE 1 firmware size and offsets Timur Kristóf
2026-04-23 11:12   ` Christian König
2026-04-23  1:16 ` [PATCH 07/11] drm/amdgpu/vce1: Stop using amdgpu_vce_resume Timur Kristóf
2026-04-23 11:13   ` Christian König
2026-04-23  1:16 ` [PATCH 08/11] drm/amdgpu/vce: Check maximum ucode size in amdgpu_vce_resume() Timur Kristóf
2026-04-23  1:16 ` [PATCH 09/11] drm/amdgpu/vce2: Fix VCE 2 firmware size and offsets Timur Kristóf
2026-04-23 11:28   ` Christian König
2026-04-23 18:10   ` John Olender
2026-04-23  1:16 ` [PATCH 10/11] drm/amdgpu/vce3: Fix VCE 3 " Timur Kristóf
2026-04-23 11:29   ` Christian König
2026-04-23  1:16 ` [PATCH 11/11] drm/amdgpu/vce4: Fix VCE 4 " Timur Kristóf
2026-04-23 11:31   ` Christian König
2026-04-23 11:50     ` Timur Kristóf [this message]

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=2603876.XAFRqVoOGU@timur-hyperion \
    --to=timur.kristof@gmail.com \
    --cc=Leo.Liu@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=john.olender@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox