Update README.md to report support of POWER and s390x #284
Conversation
| | Linux | yes² | yes¹ | yes¹ | yes¹ | yes¹ | yes¹ | | ||
| | FreeBSD | yes² | not yet | not yet | not yet | not yet | not yet | | ||
| | MacOs | yes² | not yet | N/A | N/A | no | no | | ||
| | Windows | yes² | not yet | not yet | N/A | N/A | N/A | |
There was a problem hiding this comment.
there is a question related to Windows AArch64, we have two ways to add support via software driver as we need EL1 (userland) to get info about system registers, see #186 or just read via IsProcessorFeaturePresent and HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0
the first approach is not easy, but we will have consistent features detection with Linux/FreeBSD,
the second approach is easy to get info, but IsProcessorFeaturePresent provides a small range of features detection
By the way, Linux and FreeBSD support reading features EL1 in user space (https://www.kernel.org/doc/html/latest/arm64/cpu-feature-registers.html), so we can replace impl to detection via asm if we want
Thoughts?
There was a problem hiding this comment.
also, there is an interesting fact in Windows arm64 that we can run our x86 impl and get virtual info :)
There was a problem hiding this comment.
For the purpose of this PR I will leave it as-is but we definitely want to support other ways to gather CPU info data. For instance, getting midr is a nice addition, it's a bit like the vendor and brand_string for x86.
That said, I really want to keep cpu_features as a userland library ( i.e., not a driver ). EL1 reading via filesystem under Linux / FreeBSD LGTM. Writing a driver for Windows less so.
(The raspberry pi emulating x86 on windows is amazing 😀)
There was a problem hiding this comment.
I'll close this PR but we can continue the discussion here if you want.
There was a problem hiding this comment.
Got it, so we choose reading from IsProcessorFeaturePresent, my next question is about public API should we create a separate struct for win arm64 so as not to confuse the user (for instance Aarch64WindowsInfo)? Since for the current struct Aarch64Info we have flags that IsProcessorFeaturePresent doesn't provide, for example, PF_ARM_V8_CRYPTO_INSTRUCTIONS_AVAILABLE we don't know which instructions CPU supports AES, SHA1, SHA2...
There was a problem hiding this comment.
I'll leave here FreeBSD RPI4 dmesg.boot:
CPU 0: ARM Cortex-A72 r0p3 affinity: 0
Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
Instruction Set Attributes 0 = <CRC32>
Instruction Set Attributes 1 = <>
Instruction Set Attributes 2 = <>
Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
Processor Features 1 = <>
Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA>
Memory Model Features 1 = <8bit VMID>
Memory Model Features 2 = <32bit CCIDX,48bit VA>
Debug Features 0 = <DoubleLock,2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8>
Debug Features 1 = <>
Auxiliary Features 0 = <>
Auxiliary Features 1 = <>
AArch32 Instruction Set Attributes 5 = <CRC32,SEVL>
AArch32 Media and VFP Features 0 = <FPRound,FPSqrt,FPDivide,DP VFPv3+v4,SP VFPv3+v4,AdvSIMD>
AArch32 Media and VFP Features 1 = <SIMDFMAC,FPHP DP Conv,SIMDHP SP Conv,SIMDSP,SIMDInt,SIMDLS,FPDNaN,FPFtZ>
CPU 1: ARM Cortex-A72 r0p3 affinity: 1
CPU 2: ARM Cortex-A72 r0p3 affinity: 2
CPU 3: ARM Cortex-A72 r0p3 affinity: 3There was a problem hiding this comment.
There was a problem hiding this comment.
I forgot to hit send 😅
"If windows fields are just a subset of the fields I would just keep the same structure and document which fields are not populated on Windows. If they are disjoint (some exist on windows only, others exist on linux only) then it may make sense to have different structs. For now I would just keep the same and use documentation. We can always add a different struct later on if it makes sense. Keeping the interface as small as possible has maintenance value."
There was a problem hiding this comment.
clear, thanks a lot! I will implement it for Windows and will play with parsing FreeBSD if no objections
To add Windows Arm64 support was added detection of features via Windows API function IsProcessorFeaturePresent. Added _M_ARM64 to detect CPU_FEATURES_AARCH64 macro on Windows. Added initial code for Windows Arm64 testing and provided test for Raspberry PI 4. We can't use "define_introspection_and_hwcaps.inl" as a common file for all operating systems due to msvc compiler error C2099: initializer is not a constant, so as a workaround for Windows I used separate "define_introspection.inl" See also: google#268, google#284, google#186
To add Windows Arm64 support was added detection of features via Windows API function IsProcessorFeaturePresent. Added _M_ARM64 to detect CPU_FEATURES_AARCH64 macro on Windows. Added initial code for Windows Arm64 testing and provided test for Raspberry PI 4. We can't use "define_introspection_and_hwcaps.inl" as a common file for all operating systems due to msvc compiler error C2099: initializer is not a constant, so as a workaround for Windows I used separate "define_introspection.inl" See also: google#268, google#284, google#186
* Add Windows Arm64 support To add Windows Arm64 support was added detection of features via Windows API function IsProcessorFeaturePresent. Added _M_ARM64 to detect CPU_FEATURES_AARCH64 macro on Windows. Added initial code for Windows Arm64 testing and provided test for Raspberry PI 4. We can't use "define_introspection_and_hwcaps.inl" as a common file for all operating systems due to msvc compiler error C2099: initializer is not a constant, so as a workaround for Windows I used separate "define_introspection.inl" See also: #268, #284, #186 * [CMake] Add windows_utils.h to PROCESSOR_IS_AARCH64 * Add detection of armv8.1 atomic instructions * Update note on win-arm64 implementation and move to cpuinfo_aarch64.h * Remove redundant #ifdef CPU_FEATURES_OS_WINDOWS * Add note on FP/SIMD and Cryptographic Extension for win-arm64 * Add comments to Aarch64Info fields Added comments to specify that implementer, part and variant we set 0 for Windows, since Win API does not provide a way to get information. For revision added comment that we use GetNativeSystemInfo
gchatelet
added
documentation
and removed
misc
3 participants
No description provided.