linux-stable.git/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h, branch v4.19.321

drm/amdgpu: Fix type of second parameter in trans_msg() callback

2023-01-18T10:30:35+00:00

[ Upstream commit f0d0f1087333714ee683cc134a95afe331d7ddd9 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c:412:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
          .trans_msg = xgpu_ai_mailbox_trans_msg,
                      ^~~~~~~~~~~~~~~~~~~~~~~~~
  1 error generated.

  drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c:435:15: error: incompatible function pointer types initializing 'void (*)(struct amdgpu_device *, u32, u32, u32, u32)' (aka 'void (*)(struct amdgpu_device *, unsigned int, unsigned int, unsigned int, unsigned int)') with an expression of type 'void (struct amdgpu_device *, enum idh_request, u32, u32, u32)' (aka 'void (struct amdgpu_device *, enum idh_request, unsigned int, unsigned int, unsigned int)') [-Werror,-Wincompatible-function-pointer-types-strict]
          .trans_msg = xgpu_nv_mailbox_trans_msg,
                      ^~~~~~~~~~~~~~~~~~~~~~~~~
  1 error generated.

The type of the second parameter in the prototype should be 'enum
idh_request' instead of 'u32'. Update it to clear up the warnings.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: move static CSA address to top of address space v2

2018-02-19T19:18:48+00:00

Move the CSA area to the top of the VA space to avoid clashing with
HMM/ATC in the lower range on GFX9.

v2: wrong sign noticed by Roger, rebase on CSA_VADDR cleanup, handle VA
hole on GFX9 as well.

Signed-off-by: Christian König 
Acked-by: Alex Deucher 
Acked-by: Monk Liu 
Signed-off-by: Alex Deucher

drm/amdgpu:free CSA in unified place

2017-12-06T17:47:51+00:00

instead of doing it in each GFX ip's sw_fini

Signed-off-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu:read VRAMLOST from gim

2017-12-04T21:41:45+00:00

Signed-off-by: Monk Liu 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu:cleanup in_sriov_reset and lock_reset

2017-12-04T21:41:31+00:00

since now gpu reset is unified with gpu_recover
for both bare-metal and SR-IOV:

1)rename in_sriov_reset to in_gpu_reset
2)move lock_reset from adev->virt to adev

Signed-off-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu:implement new GPU recover(v3)

2017-12-04T21:41:30+00:00

1,new imple names amdgpu_gpu_recover which gives more hint
on what it does compared with gpu_reset

2,gpu_recover unify bare-metal and SR-IOV, only the asic reset
part is implemented differently

3,gpu_recover will increase hang job karma and mark its entity/context
as guilty if exceeds limit

V2:

4,in scheduler main routine the job from guilty context  will be immedialy
fake signaled after it poped from queue and its fence be set with
"-ECANCELED" error

5,in scheduler recovery routine all jobs from the guilty entity would be
dropped

6,in run_job() routine the real IB submission would be skipped if @skip parameter
equales true or there was VRAM lost occured.

V3:

7,replace deprecated gpu reset, use new gpu recover

Signed-off-by: Monk Liu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu/virt: add wait_reset virt ops

2017-12-04T21:33:13+00:00

Driver can use this interface to check if there's a function level
reset done in hypervisor. It's helpful when IRQ handler for reset
is not ready, or special handling is required.

Acked-by: Alex Deucher 
Reviewed-by: Monk Liu 
Signed-off-by: pding 
Signed-off-by: Alex Deucher

drm/amdgpu/virt: add function to check MMIO (v2)

2017-12-04T21:33:13+00:00

MMIO space can be blocked on virtualised device. Add this
function to check if MMIO is blocked or not.

Todo: need a reliable method such like communation
with hypervisor.

v2:
 - add comments inline

Signed-off-by: pding 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: SR-IOV data exchange between PF&VF

2017-10-19T19:26:59+00:00

SR-IOV need to exchange some data between PF&VF through shared VRAM

PF will copy some necessary firmware and information to the shared
VRAM. It also requires some information from VF. PF will send a
key through mailbox2 to help guest calculate checksum so that it can
verify whether the data is correct.

So check the data on the specified offset of the shared VRAM, if the
checksum is right, read values from it and write some VF information
next to the data from PF.

Signed-off-by: Horace Chen 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix vf error handling

2017-09-28T20:03:20+00:00

The error handling for virtual functions assumed a single
vf per VM and didn't properly account for bare metal.  Make
the error arrays per device and add locking.

Reviewed-by: Gavin Wan 
Signed-off-by: Alex Deucher