linux-kernel - Re: [PATCH v3 2/4] cacheinfo: Check cache properties are present in DT

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c58fa005-49a6-ef46-ded8-c9246d4a989b@arm.com>
Date:   Fri, 14 Apr 2023 09:33:09 +0200
From:   Pierre Gondois <pierre.gondois@....com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Sudeep Holla <sudeep.holla@....com>
Cc:     linux-kernel@...r.kernel.org, Radu Rendec <rrendec@...hat.com>,
        Alexandre Ghiti <alexghiti@...osinc.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Will Deacon <will@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Palmer Dabbelt <palmer@...osinc.com>,
        Gavin Shan <gshan@...hat.com>
Subject: Re: [PATCH v3 2/4] cacheinfo: Check cache properties are present in
 DT



On 4/13/23 22:06, Florian Fainelli wrote:
> On 4/13/23 12:50, Sudeep Holla wrote:
>> On Thu, Apr 13, 2023 at 11:16:37AM -0700, Florian Fainelli wrote:
>>> On 4/13/23 02:14, Pierre Gondois wrote:
>>>> If a Device Tree (DT) is used, the presence of cache properties is
>>>> assumed. Not finding any is not considered. For arm64 platforms,
>>>> cache information can be fetched from the clidr_el1 register.
>>>> Checking whether cache information is available in the DT
>>>> allows to switch to using clidr_el1.
>>>>
>>>> init_of_cache_level()
>>>> \-of_count_cache_leaves()
>>>> will assume there a 2 cache leaves (L1 data/instruction caches), which
>>>> can be different from clidr_el1 information.
>>>>
>>>> cache_setup_of_node() tries to read cache properties in the DT.
>>>> If there are none, this is considered a success. Knowing no
>>>> information was available would allow to switch to using clidr_el1.
>>>>
>>>> Fixes: de0df442ee49 ("cacheinfo: Check 'cache-unified' property to count cache leaves")
>>>> Reported-by: Alexandre Ghiti <alexghiti@...osinc.com>
>>>> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/
>>>> Signed-off-by: Pierre Gondois <pierre.gondois@....com>
>>>
>>> Humm, it would appear that the cache levels and topology is still provided,
>>> despite the lack of cache properties in the Device Tree which is intended by
>>> this patch set however we lost the size/ways/sets information, could we not
>>> complement the missing properties here?
>>>
>>
>> I am confused. How and from where the information was fetched before this
>> change ?
> 
> I applied Pierre's patches to my tree and then did the following:
> 
> - before means booting with the patches applied and the Device Tree
> providing cache information: {d,i}-cache-{size,line-size,sets} and
> next-level-cache
> 
> - after means removing all of those properties still with the patches
> applied
> 
> My expectation is that if we omit the properties in the Device Tree, we
> will fallback to reading that information out of clidr_el1. However as
> can be seen from the "before" and "after" outputs, there is loss of
> information, as we no longer have the cacheline size, number of
> sets/ways, the rest is valid though.
> 
> So my question is whether this is expected and in scope of what is being
> done here, or not.
> 
>>
>>> If this is out of the scope of what you are doing:
>>>
>>> Tested-by: Florian Fainelli <f.fainelli@...il.com>
>>>
>>
>> Just looking at the lscpu output before and after, it looks something is
>> broken. What am I missing here ?
>>
> 
> What is broken in the "before" output? It contains the entire set of
> possible information we know about the caches. As for the "after", well
> yes there is information missing, the whole point of my email actually...

I think this is the expected behaviour. There are other registers containing
cache information, like CCSIDR_EL1 and CCSIDR2_EL1.
However the information contained in CCSIDR_EL1 cannot really be trusted, cf [1]:
| You cannot make any inference about the actual sizes of caches based
| on these parametersand Arm spec.

and for CCSIDR2_EL1 I assume that knowing the number of cache sets is not a
crucial information.

So if there is no cache information in DT/ACPI, the only information extracted
from registers is the level/type of caches coming from CLIDR_EL1.

Regards,
Pierre

[1] https://lore.kernel.org/all/1489177945-8590-2-git-send-email-will.deacon@arm.com/