Page MenuHomeFreeBSD

arm64: export new HWCAP features
ClosedPublic

Authored by mhorne on Aug 11 2020, 7:35 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 16, 7:23 AM
Unknown Object (File)
Fri, Apr 12, 9:42 AM
Unknown Object (File)
Fri, Apr 12, 6:00 AM
Unknown Object (File)
Wed, Apr 10, 5:45 PM
Unknown Object (File)
Mar 14 2024, 7:34 AM
Unknown Object (File)
Mar 14 2024, 7:34 AM
Unknown Object (File)
Mar 8 2024, 8:29 AM
Unknown Object (File)
Feb 14 2024, 10:47 AM
Subscribers

Details

Summary

This includes the addition of elf_hwcap2 into the sysvec, and a separate
function to parse for those features.

This only exposes features which require no further configuration, e.g.
indicating the presence of certain instructions. Larger features (SVE)
will not be advertised until we actually support them.

Reference: https://www.kernel.org/doc/html/v5.8/arm64/elf_hwcaps.html

Diff Detail

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

Event Timeline

sys/arm64/arm64/identcpu.c
1148 ↗(On Diff #75697)

Suppose CPUs 0 and 1 have different capabilities: CPU 0 has no capabilities covered by the elf_hwcap2 mask, but CPU 1 has at least one. Then, when cpu == 1 we will see that elf_hwcap2 == 0 and set elf_hwcap2 to the set of CPU 1's capabilities even though they are not shared by all CPUs.

I suppose this could happen with elf_hwcap too, but it seems less likely that a CPU has no capabilities in that set.

sys/arm64/arm64/identcpu.c
1148 ↗(On Diff #75697)

That's a good point. I think instead we could initialize elf_hwcap2 to (u_long)-1 and use &= all the way.

Do any of the new caps require kernel support before they can be used? If so we shouldn't report them to the user until that support is in place.

sys/arm64/arm64/identcpu.c
1148 ↗(On Diff #75697)

I think we should be using user_cpu_desc to set both elf_hwcap and elf_hwcap2. This will ensure we are consistent with what we report through both methods.

Do any of the new caps require kernel support before they can be used? If so we shouldn't report them to the user until that support is in place.

Not as far as I know, most simply indicate the presence of instructions. I need to do a second reading to be sure before committing.

Expose SSBS in user_cpu_desc. Annotate elf_hwcap and elf_hwcap2 as __read_frequently.

Do any of the new caps require kernel support before they can be used? If so we shouldn't report them to the user until that support is in place.

Not as far as I know, most simply indicate the presence of instructions. I need to do a second reading to be sure before committing.

ARMv8.5-BTI will require some work in the kernel before it can be exposed to userspace, so it is still gated behind user_cpu_desc. The rest of these features are safe to expose.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 8 2020, 3:36 PM
This revision was automatically updated to reflect the committed changes.