linux-kernel - Re: [PATCH v2] drm/panfrost:report the full raw fault information instead

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3c68f653-708a-5de9-4227-2a8abc88dc74@arm.com>
Date:   Mon, 5 Jul 2021 14:50:47 +0100
From:   Steven Price <steven.price@....com>
To:     Chunyou Tang <tangchunyou@....com>
Cc:     tomeu.vizoso@...labora.com, airlied@...ux.ie,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        alyssa.rosenzweig@...labora.com,
        ChunyouTang <tangchunyou@...becorp.cn>
Subject: Re: [PATCH v2] drm/panfrost:report the full raw fault information
 instead

On 02/07/2021 02:40, Chunyou Tang wrote:
> Hi Steve,
>> You didn't answer my previous question:
>>
>>> Is this device working with the kbase/DDK proprietary driver?
> 
> I don't know whether I used kbase/DDK,I only know I used the driver of
> panfrost in linux 5.11.

kbase is the Linux kernel driver for Arm's proprietary driver. The
proprietary driver from Arm is often called "the [Mali] DDK" by Arm (or
"the blob" by others). I guess "libmali.so" is the closest it has to a
real name.

>> What you are describing sounds like a hardware integration issue, so
>> it would be good to check that the hardware is working with the
>> proprietary driver to rule that out. And perhaps there is something
>> in the kbase for this device that is setting a chicken bit to 'fix'
>> the coherency?
> 
> I don't have the proprietary driver,I only used driver in linux 5.11.

Interesting - I would have expected the initial hardware bring up to
have happened with the proprietary driver from Arm. And my first step
would be to check whether any workarounds for integration issues were
applied in the kernel.

I think we'd need some input from the people who did the hardware
integration, and hopefully they would have access to the proprietary
driver from Arm.

Steve

> Thinks very much!
> 
> Chunyou.
> 
> 
> 于 Thu, 1 Jul 2021 11:15:14 +0100
> Steven Price <steven.price@....com> 写道:
> 
>> On 29/06/2021 04:04, Chunyou Tang wrote:
> 
> 
>>> Hi Steve,
>>> 	thinks for your reply.
>>> 	I set the pte in arm_lpae_prot_to_pte(),
>>> ***********************************************************************
>>> 	/*
>>> 	 * Also Mali has its own notions of shareability wherein its
>>> Inner
>>> 	 * domain covers the cores within the GPU, and its Outer
>>> domain is
>>> 	 * "outside the GPU" (i.e. either the Inner or System
>>> domain in CPU
>>> 	 * terms, depending on coherency).
>>> 	 */
>>> 	if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE)
>>> 		pte |= ARM_LPAE_PTE_SH_IS;
>>> 	else
>>> 		pte |= ARM_LPAE_PTE_SH_OS;
>>> ***********************************************************************
>>> I set pte |= ARM_LPAE_PTE_SH_NS.
>>>
>>> 	If I set pte to ARM_LPAE_PTE_SH_OS or
>>> 	ARM_LPAE_PTE_SH_IS,whether I use singel core GPU or multi
>>> core GPU,it will occur GPU Fault.
>>> 	if I set pte to ARM_LPAE_PTE_SH_NS,whether I use singel core
>>> 	GPU or multi core GPU,it will not occur GPU Fault.
>>
>> Hi,
>>
>> So this is a difference between Panfrost and kbase. Panfrost (well
>> technically the IOMMU framework) enables the inner-shareable bit for
>> all memory, whereas kbase only enables it for some memory types (the
>> BASE_MEM_COHERENT_LOCAL flag in the UABI controls it). However this
>> should only be a performance/power difference (and AFAIK probably an
>> irrelevant one) and it's definitely required that "inner shareable"
>> (i.e. within the GPU) works for communication between the different
>> units of the GPU.
>>
>> You didn't answer my previous question:
>>
>>> Is this device working with the kbase/DDK proprietary driver?
>>
>> What you are describing sounds like a hardware integration issue, so
>> it would be good to check that the hardware is working with the
>> proprietary driver to rule that out. And perhaps there is something
>> in the kbase for this device that is setting a chicken bit to 'fix'
>> the coherency?
>>
>> Steve
> 
>