bug#74731: guix/cpu should parse /sys/devices/system/cpu/modalias

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

On Mon, Dec 09, 2024 at 06:37:22PM +0100, Ludovic Courtès wrote:
> Hello,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > I saw a post by Marcan¹ of Asahi Linux the other day about not parsing
> > /proc/cpuinfo and remembered that's what we're doing in (guix cpu).
> 
> I believe it initially mimicked what GCC does for ‘-march=native’, but
> it does seem to be less exhaustive than /sys/devices/cpu/modalias.
> 
> I wonder if there are version/portability issues with the latter.

I've been thinking more about it over the past few days.

I think ultimately we need to match both parts; the kernel interfaces
with the hardware and knows (or at least should know) exactly what the
hardware can support, and gcc (or the other compilers) need to support
optimizing for those hardware bits specifically.

Also, parsing /proc/cpuinfo is already reading what the kernel says it
supports, except in an incomplete manner.

Starting with x86_64 (and i686), I think we keep GCC's definition of
what each sub-architecture is but parse the modalias file instead of
parsing cpuinfo.

I already have some code to parse modalias and some ideas for just
reusing the math bits from the kernel (it looks like ((11*32)+28) for
zen2) to adjust the if-flags to match the numerical equivalent of the
feature.

For x86_64 the kernel does have a policy of reusing flags if they've
been deprecated and unused long enough, but hopefully that won't be a
problem, even with some of our older LTS kernels.

I think for the start it would make most sense to read modalias in
addition to cpuinfo, sort based on the data in modialis, and then
fallback to cpuinfo if it doesn't match.  This helps for architectures
without the modalias file (like riscv64), and I don't know what the Hurd
provides, but I'd be surprised if it had the same modalias file for
parsing.

I'll try to work on it a bit over the coming days.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]