arm64: Add HWCAP support

[manu]

Summary

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

[andrew]

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]

In D17137#365425, @andrew wrote:

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 ?

[val_packett.cool]

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.

[andrew]

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

[mmel]

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.

[val_packett.cool]

In D17137#393947, @andrew wrote:

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]

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

[manu]

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