This should have been fixed by this commit in amd-staging-drm-next:
https://lore.kernel.org/patchwork/patch/1392368/
commit b8aff1f3a0b3d8434f8ccf5d3017137c29aca77b
Author: Felix Kuehling
Date: Mon Mar 8 22:15:42 2021 -0500
drm/amdkfd: fix build error with AMD_IOMMU_V2=m
Using
Am 2021-03-26 um 5:38 a.m. schrieb Qu Huang:
> On 2021/1/28 5:50, Felix Kuehling wrote:
>> Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang:
>>> Amdgpu driver uses 4-byte data type as DQM fence memory,
>>> and transmits GPU address of fence memory to microcode
>>&
Am 2021-03-23 um 10:56 a.m. schrieb Alex Deucher:
> Applied. Thanks!
Thanks. I thought we fixed this before by making the file write-only.
But I guess that's not sufficient to stop root from reading it:
commit 2bdac179e217a0c0b548a8c60524977586621b19
Author: Felix Kuehling
Date: Th
This caused a regression in kfdtest in a large-buffer stress test after
memory allocation for user pages fails:
[17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16
[17359.543746] BUG: kernel NULL pointer dereference, address:
[17359.551494] #PF: supervisor read
On 2021-03-09 11:50 a.m., Felix Kuehling wrote:
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_6
IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Report
Am 2021-03-09 um 3:58 a.m. schrieb Arnd Bergmann:
> On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
>> against the exported functions. If the GPU driver is built-in but the
>> IOMMU d
IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reporte
Am 2021-03-08 um 3:45 p.m. schrieb Arnd Bergmann:
> From: Arnd Bergmann
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but
Am 2021-03-08 um 2:33 p.m. schrieb Arnd Bergmann:
> On Mon, Mar 8, 2021 at 8:11 PM Felix Kuehling wrote:
>> Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
>>> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling
>>> wrote:
>>>> The driver build should work
Am 2021-03-08 um 2:05 p.m. schrieb Arnd Bergmann:
> On Mon, Mar 8, 2021 at 5:24 PM Felix Kuehling wrote:
>> The driver build should work without IOMMUv2. In amdkfd/Makefile, we
>> have this condition:
>>
>> ifneq ($(CONFIG_AMD_IOMMU_V2),)
>> AMDKFD_FILES += $(
The driver build should work without IOMMUv2. In amdkfd/Makefile, we
have this condition:
ifneq ($(CONFIG_AMD_IOMMU_V2),)
AMDKFD_FILES += $(AMDKFD_PATH)/kfd_iommu.o
endif
In amdkfd/kfd_iommu.h we define inline stubs of the functions that are
causing your link-failures if IOMMU_V2 is not enabled:
Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang:
> Amdgpu driver uses 4-byte data type as DQM fence memory,
> and transmits GPU address of fence memory to microcode
> through query status PM4 message. However, query status
> PM4 message definition and microcode processing are all
> processed according
ting to out-of-bounds memory.
>
> Fixes: b7b6c38529c9 ("drm/amdkfd: Calculate CPU VCRAT size dynamically (v2)")
> Suggested-by: Felix Kuehling
> Signed-off-by: Jeremy Cline
Thanks. I'll apply this patch.
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/
Am 2021-01-08 um 11:31 a.m. schrieb Jeremy Cline:
> KASAN reported a slab-out-of-bounds read of size 1 in
> kdf_create_vcrat_image_cpu().
>
> This occurs when, for example, when on an x86_64 with a single NUMA node
> because kfd_fill_iolink_info_for_cpu() is a no-op, but afterwards the
> sub_type_h
t in the driver, and revise fallback
function if CRAT is broken.
v5: refine acpi crat good but no iommu support case, and rename the
title.
v6: fix the issue of dGPU initialized firstly, just modify the report
value in the node_show().
Signed-off-by: Huang Rui
Am 2020-11-12 um 10:11 p.m. schrieb Hanjun Guo:
> If the ignore_crat is set to non-zero value, it's no point getting
> the CRAT table, so just move the ignore_crat check before we get the
> CRAT table.
>
> Signed-off-by: Hanjun Guo
Thank you! I applied the patches.
Regards,
Felix
> ---
> dr
On 2020-11-04 10:13 a.m., Deepak R Varma wrote:
idr_init() uses base 0 which is an invalid identifier. The new function
idr_init_base allows IDR to set the ID lookup from base 1. This avoids
all lookups that otherwise starts from 0 since 0 is always unused.
I disagree. We call idr_alloc with st
ven_device_info = {
> ^
>
> As Huang Rui suggested, Raven already has the fallback path,
> so it should be out of IOMMU v2 flag.
>
> Suggested-by: Huang Rui
> Signed-off-by: YueHaibing
Reviewed-by: Felix Kuehling
I applied yo
tialize on Raven when SME is active? There is a global
>> checking function for that, so that shouldn't be hard to do.
>>
> Sure. How about the attached patch?
The patch is
Acked-by: Felix Kuehling
Thanks,
Felix
>
> Alex
>
Am 2020-08-28 um 9:46 a.m. schrieb jroe...@suse.de:
> On Wed, Aug 26, 2020 at 03:25:58PM +, Deucher, Alexander wrote:
>>> Alex, do you know if anyone has tested amdgpu on an APU with SME
>>> enabled? Is this considered something we support?
>> It's not something we've tested. I'm not even sure
Am 2020-08-26 um 4:29 a.m. schrieb Hanjun Guo:
> If the ignore_crat is set to non-zero value, it's no point getting
> the CRAT table, so just move the ignore_crat check before we get the
> CRAT table.
>
> Signed-off-by: Hanjun Guo
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
>
[+Ray]
Thanks for the heads up. Currently KFD won't work on APUs when IOMMUv2
is disabled. But Ray is working on fallbacks that will allow KFD to work
on APUs even without IOMMUv2, similar to our dGPUs. Along with changes
in ROCm user mode, those fallbacks are necessary for making ROCm on APUs
ge
Hi Hanjun,
Sorry for the late reply.
Thank you for the patch and the explanation. This seems to have been
broken since the first version of KFD in 2014. See one suggestion inline.
Am 2020-07-22 um 5:48 a.m. schrieb Hanjun Guo:
> The acpi_get_table() should be coupled with acpi_put_table() if
> t
Am 2020-07-02 um 3:10 p.m. schrieb Fenghua Yu:
> Hi, Felix, Thomas, Joerg and maintainers,
>
> On Tue, Jun 30, 2020 at 10:12:38PM -0400, Felix Kuehling wrote:
>> Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu:
>> You didn't change the return types of amdgpu_pasid_al
Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu:
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with uapi
> definitions, define PASID and its variations (e.g. max PASID) as "u32".
> "u32" is also shorter and a little mo
anch this memory not free. If use
> kmemleak, this path maybe catched.
> These changes are to add kobject_put in kobject_init_and_add
> failed branch, fix potential memleak.
>
> Signed-off-by: Bernard Zhao
The patch is
Reviewed-by: Felix Kuehling
I'll apply it to amd-staging
Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter:
> On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
>>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
>>>>> I still have my doubts
Hi Bernard,
I just applied a patch from another contributor for the kfd_topology
part of this. See
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=fc0fe8138309fee303bd12991f12b23f01bbf58c
Please rebase your patch on that. I believe that should only leave the
fixes in k
Am 2020-06-19 um 3:55 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
>> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
>>> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>>>> On Fri, Jun 19, 2
Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mm
Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mmu notifier
is
Reviewed-by: Felix Kuehling
I'm applying the patch to our amd-staging-drm-next branch.
Regards,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology
Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
>>> I still have my doubts about allowing fence waiting from within shrinkers.
>>> IMO ideally they should use a trywait approach, in order to allow memory
>>> allocation during com
check")
Fixes: 522b89c63370 ("drm/amdkfd: Track SDMA utilization per process")
Signed-off-by: Colin Ian King
Reviewed-by: Felix Kuehling
I applied the patch to our internal amd-staging-drm-next.
Regards,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +++--
e one comment inline. With that fixed, the patch is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++--
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> b
ent.
>
> Fix this by using 'enum kfd_preempt_type' for (*hqd_destroy) too.
>
> Signed-off-by: Luc Van Oostenryck
Interesting. I'm surprised I never saw a compiler warning about a
function pointer type mismatch. I guess C isn't picky about integer
types as long as the size
[+Philip]
On 2018-04-20 10:47 AM, Michel Dänzer wrote:
> On 2018-04-11 11:37 AM, Christian König wrote:
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>> :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
> Hi Christian,
>
> Thanks for
>>> Signed-off-by: Arnd Bergmann
>>
>> Acked-by: Christian König , but I would wait on
>> what Felix says to that.
> Tested-by: Anders Roxell
>
> Randy sent the same patch [1] and its still required.
>
> Cheers,
> Anders
> [1] https://patchwork.kern
zeof(uint32_t))];
> + if (dev->device_info->ih_ring_entry_size > (8 * sizeof(uint32_t))) {
> + dev_err(kfd_chardev(), "Ring entry too small\n");
When the ring entry size really is too small, this will potentially
flood the kernel log. Maybe a WARN_ONCE would be m
Thanks Christian for catching that. I'm working on a patch series to
upstream Vega10 support, about 95% done. It will add this ASIC info for
Vega10:
static const struct kfd_device_info vega10_device_info = {
.asic_family = CHIP_VEGA10,
.max_pasid_bits = 16,
.max_no_of_hqd
This patch is Reviewed-by: Felix Kuehling
On 2018-03-29 10:25 PM, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning:
> symbol 'kfd_dev_is_large_bar' was not declared. Should it be static?
>
>
Thanks for catching that. I'd use -ENODEV to match what is done a few
lines below for peer_pdd. With that fixed, this patch is Reviewed-by:
Felix Kuehling
Regards,
Felix
On 2018-03-29 10:25 PM, Wei Yongjun wrote:
> Passing NULL pointer to PTR_ERR will result in return value of 0
>
Looks good. This change is Reviewed-by: Felix Kuehling
Regards,
Felix
On 2018-01-18 07:39 PM, Gustavo A. R. Silva wrote:
> Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element.
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gust
Yeah, this looks good to me.
Regards,
Felix
On 2018-01-10 04:58 PM, Gustavo A. R. Silva wrote:
> Hi Felix,
>
> Quoting Felix Kuehling :
>
>> Hi Gustavo,
>>
>> Thanks for catching that. When returning a fault, I think you also need
>> to srcu_
Hi Gustavo,
Thanks for catching that. When returning a fault, I think you also need
to srcu_read_unlock(&kfd_processes_srcu, idx).
However, instead of returning an error, I think I'd prefer to skip PDDs
that can't be found with continue statements. That way others would
still suspend and resume s
This commit is Reviewed-by: Felix Kuehling
Thanks,
Felix
On 2018-01-08 07:53 AM, Arnd Bergmann wrote:
> The newly added get_local_mem_info() function prints a phys_addr_t
> using 0x%llx, which is wrong on most 32-bit systems, as shown by
> this warning:
>
> drivers/gpu
On 2017-11-02 07:26 AM, Arnd Bergmann wrote:
> It seems impossible to build this driver without setting either
> CONFIG_DEBUG_KERNEL or CONFIG_DEBUG_DRIVER:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h: In function
> 'set_reg_field_value_ex':
> drivers/gpu/drm/amd/amdgpu/../display/d
Looks like we need to include sched.h before mmu_context.h to make the
Alpha build happy.
Regards,
Felix
On 2017-09-16 09:50 PM, kbuild test robot wrote:
> Hi Felix,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> mast
On 2017-09-15 05:14 PM, Andrew Morton wrote:
> On Mon, 28 Aug 2017 21:53:10 -0400 Felix Kuehling
> wrote:
>
>> This adds a statically sized closed hash table implementation with
>> low memory and CPU overhead. The API is inspired by kfifo.
>>
>> Storing, retr
entries relocated to speed up future lookups.
Signed-off-by: Felix Kuehling
Acked-by: Christian König
---
This is part of a larger patch series I'm working on to support
demand-paging on AMD Vega10 and similar AMD GPUs. Vega10 generates a
flood of page fault events in its interrupt ring buffe
I must have added that accidentally when cherry-picking an internal
patch for upstreaming. Thanks for catching it.
Reviewed-by: Felix Kuehling
Regards,
Felix
On 2017-08-23 09:17 AM, Colin King wrote:
> From: Colin Ian King
>
> Remove a redundant identical return statement, it h
arish Kasiviswanathan
Reviewed-by: Felix Kuehling
---
Current KFD with AMD discrete GPU support is not yet upstream, but we
are working on getting it upstream for 4.13 or 4.14 depending on how we
line up with Dave Airlie's merge windows.
For reference, recent releases of ROCm (AMD's Rade
On 16-11-25 12:20 PM, Serguei Sagalovitch wrote:
>
>> A white list may end up being rather complicated if it has to cover
>> different CPU generations and system architectures. I feel this is a
>> decision user space could easily make.
>>
>> Logan
> I agreed that it is better to leave up to user sp
On 16-11-25 03:40 PM, Christian König wrote:
> Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe:
>> This assumes the commands are fairly short lived of course, the
>> expectation of the mmu notifiers is that a flush is reasonably prompt
>
> Correct, this is another problem. GFX command submissions u
On 16-01-21 05:20 PM, Felix Kuehling wrote:
> I'm running into circular lock dependencies reported by lockdep that
> involve read-locks and should not be flagged as deadlocks at all. I
> wrote a very simple test function that demonstrates the problem:
[snip]
> It sets up a circula
I'm running into circular lock dependencies reported by lockdep that
involve read-locks and should not be flagged as deadlocks at all. I
wrote a very simple test function that demonstrates the problem:
> static void test_lockdep(void)
> {
> struct mutex fktest_m;
> struct rw_semaphore
57 matches
Mail list logo