I think we are in agreement here.  comments below.

On 2024-07-12 16:24, Stuart Henderson wrote:
> On 2024/07/12 16:08, j@bitminer.ca wrote:
>> Some features are fairly complicated to understand; e.g. the array
>> of avx instructions varies dramatically with implementation (code
>> name of the cpu). Fortunately cpuid on Intel is unprivileged so
>> software can decide
> 
> Well, with avx512, it also depends on whether the OS supports it. If 
> not
> then no matter what CPU, it won't work.

Yes, and the porter is obliged to limit compiled instructions to avoid
failure.  Or, for some codes, to ensure executed instructions fall 
within
the cpu feature set because the code adapts to the currently executing 
cpu.

If the OS does not support the executed instructions at best you
get an illegal instruction fault.

> 
>> then the porter has to understand this and somehow restrict usage.
> 
> if the OS can restrict the information presented to userland when it
> knows that something won't work, that makes things much simpler for
> the porter (who often won't have enough hardware variants to test).
> 
>> If SVE is not available (because context switch does not preserve
>> the register file) then so be it.  Again the porter has to control
>> for this.
> 
> Not if the OS can control for this.
> 

As above, the porter wants to avoid illegal instruction faults.

>> To be sure, I would support a dmesg output which matches, within
>> the supported features
> 
> Requiring that a port parse dmesg for cpu features is complete 
> bullshit.
> 

Agreed.  But developers don't see it that way.  Examples: blis, numpy.

Hence my request. s;/proc/cpuinfo;/var/run/dmesg.boot;g simplifies
life for the porters.

If the source for the port uses other means then porters will adapt 
those.

>> > > In particular you may well find that some of these codepaths break
>> > > branch-target CFI.
>> 
>> Interesting risk there.  is there somewhere to learn more?
> 
> https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension

thanks


J