Page MenuHomeFreeBSD

arm64: Add HWCAP support
ClosedPublic

Authored by manu on Sep 12 2018, 5:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 25 2024, 1:01 PM
Unknown Object (File)
Feb 4 2024, 8:50 AM
Unknown Object (File)
Jan 13 2024, 11:28 AM
Unknown Object (File)
Dec 18 2023, 5:29 AM
Unknown Object (File)
Nov 26 2023, 8:25 AM
Unknown Object (File)
Nov 26 2023, 5:55 AM
Unknown Object (File)
Nov 23 2023, 11:57 PM
Unknown Object (File)
Nov 23 2023, 11:18 PM

Details

Summary

Since we parse all the registers in print_cpu_features, fill the date
there.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This is broken on big little SoCs that have different features on the different clusters, we need to ensure the HWCAP is the union of what all CPUs support.

Additionally, I was hoping we didn't need to support HWCAPs on arm64. I added support to read the ID registers from userspace. We just need to add the parts to set useful values.

This is broken on big little SoCs that have different features on the different clusters, we need to ensure the HWCAP is the union of what all CPUs support.

Does that exists ?

Additionally, I was hoping we didn't need to support HWCAPs on arm64. I added support to read the ID registers from userspace. We just need to add the parts to set useful values.

Well we already have elf_aux_info so why not using it so ports could benefit from it ?

HWCAP as union of all CPUs' features would be pretty helpful. Reading the registers on all CPUs from userspace by setting thread affinity to each CPU in sequence is a bit inconvenient.

There is no need to set the cpu affinity, the userspace register view is the same on each core.

Imho, aggregated reading of ID registers is not a best solution.
Personally, I think that we should implement aggregated view by using HWCAPS (As we must do this in any case, upcoming COMPAT32 simply expects this).
But we should return actual/real values of ID registers. This allow us to write program which iterates over clusters and selects best cores for given workload.
I mainly talking about SHA or SVE extensions here.

There is no need to set the cpu affinity, the userspace register view is the same on each core.

So it's already doing the union (minimum supported feature set)? Well that makes it easy! Nice.

In D17137#393953, @mmel wrote:

Imho, aggregated reading of ID registers is not a best solution.
Personally, I think that we should implement aggregated view by using HWCAPS (As we must do this in any case, upcoming COMPAT32 simply expects this).
But we should return actual/real values of ID registers. This allow us to write program which iterates over clusters and selects best cores for given workload.
I mainly talking about SHA or SVE extensions here.

If we're already returning the union, switching to returning real values would technically be a compatibility break that would require userspace to either switch to hwcaps or check all cores.. Not that a lot of userspace does any of this right now (I'm currently writing a patch to Rust's stdsimd)..

Either way, heterogeneous chips with different capabilities don't seem very common. So far only that silly Samsung mobile SoC has mixed ARMv8.0 and ARMv8.2 clusters, I don't think anyone else is doing that currently. So while "select best cores" sounds very nice in theory, I'm not sure it's going to be done much in practice. Developers are lazy :) So always returning the union might be good enough.

Add a new function to parse the different cpu cap and only report the common caps.

I'd like to commit that soon, anyone have objections ?

This revision was not accepted when it landed; it landed in state Needs Review.Jul 20 2019, 2:29 PM
Closed by commit rS350166: arm64: Implement HWCAP (authored by manu). · Explain Why
This revision was automatically updated to reflect the committed changes.