perf usage of arch/arm64/include/asm/cputype.h

[Yicong Yang]

On 2025/6/18 19:24, Leo Yan wrote:
> On Wed, Jun 18, 2025 at 09:52:53AM +0100, Mark Rutland wrote:
> 
> [...]
> 
>>>> Other than that, I think that userspace should just maintain its own
>>>> infrastructure, and only pull in things from kernel sources when there's
>>>> a specific reason to. Otherwise we're just creating busywork.
>>>
>>> I agree with the methodology.
>>>
>>> Since Arnaldo is facing build failure when sync headers between kernel
>>> and perf tool, to avoid long latency, let us split the refactoriing
>>> into separate steps.
>>>
>>> As a first step, I think my previous suggestion is valid, we can create a
>>> header tools/perf/arch/arm64/include/cputype.h with below code:
>>>
>>>   #include "../../../../arch/arm64/include/asm/cputype.h"
>>
>> Directly including the kernel header introduces the very fragility that
>> having a copy was intended to avoid. NAK to that.
> 
> My suggestion is not to include the kernel header, nor to modify the
> copy header. :)
> 
> Instead, I suggested creating a new header within the perf tool (under
> perf's arm64 folder) and then include the copy header in tools:
> 
>   tools/arch/arm64/include/asm/cputype.h
> 

sorry for the misunderstood.:(
in this way we still have the divergency in the long term and as a workaround
this works same if we partly update the tools/arch/arm64/include/asm/cputype.h
with only necessary MIDR updates and keep is_midr_in_range_list() unchanged.

>> I've replied to the same effect Yicong's patch [1,2].
>>
>> If we want to share headers between userspace and kernel, we should
>> refactor those headers such that this is safe by construction.
>>
>> There is no need to update the userspace headers just because the kernel
>> headers have changed, so the simple solution in the short term is to
>> suppress the warning from check-headers.sh.
> 
> Sure, makes sense for me.
> 
> @Arnaldo, as Mark suggested, do you want me to send a patch to remove
> cputype.h checking in check-headers.sh or it is fine to keep the warning
> until finish the header refactoring?
> 
> @Yicong, could you confirm if you proceed to refactor the MIDR? thanks!
> 

please feel free to take this over.

> Just note, I searched tools folder and found kselftest also uses the
> cputype.h header. The refactoring should not break the files below.
> 

they shouldn't affected. I did a kselftest build test with my latest patch
and they were not affected.

thanks.

> $ git grep cputype.h
> perf/check-headers.sh:check arch/arm64/include/asm/cputype.h '-I "^#include [<\"]\(asm/\)*sysreg.h"'
> perf/util/arm-spe.c:#include "../../arch/arm64/include/asm/cputype.h"
> testing/selftests/kvm/arm64/psci_test.c:#include <asm/cputype.h>
> testing/selftests/kvm/lib/arm64/vgic.c:#include <asm/cputype.h>
> 
> Thanks,
> Leo
> 
>> [1] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m23dfbea6af559f3765d89b9d8427213588871ffd
>> [2] https://lore.kernel.org/linux-arm-kernel/dc5afc5c-060c-8bcb-c3a7-0de49a7455fb@huawei.com/T/#m6acbfa00002af8ee791266ea86a58f8f994ed710
>>
>> Mark.
>>
>>>
>>>   static bool is_perf_midr_in_range_list(u32 midr,
>>>                                          struct midr_range const *ranges)
>>>   {
>>>           while (ranges->model) {
>>>                   if (midr_is_cpu_model_range(midr, ranges->model,
>>>                                   ranges->rv_min, ranges->rv_max))
>>>                           return true;
>>>                   ranges++;
>>>           }
>>>
>>>           return false;
>>>   }
>>>
>>> Then, once we can generate a dynamic MIDR header file, we can use that
>>> header and define the midr_range structure specifically in the perf.
>>> In the end, perf can avoid to include kernel's cputype.h.
>>>
>>> If no objection, Yicong, do you mind preparing the patch mentioned
>>> above? Thanks!
>>>
>>> Leo
> 
> .
>