Page MenuHomeFreeBSD

arm64: Add HWCAP support
ClosedPublic

Authored by manu on Sep 12 2018, 5:50 PM.

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

manu created this revision.Sep 12 2018, 5:50 PM

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.

manu added a comment.Sep 12 2018, 8:37 PM

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.

mmel added a comment.Dec 9 2018, 12:30 PM

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.

manu updated this revision to Diff 56656.Apr 25 2019, 5:52 PM

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

manu added a comment.Jul 15 2019, 5:27 PM

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.