Windows-2025 advertises incorrect CPUID for AMX leaf on Emerald Rapids (EMR)

[rahulchaphalkar]

Description

windows-2025 runner advertises cpuid.7 and XCR0 with AMX support -

INTEL(R) XEON(R) PLATINUM 8573C
CPUID.1:ECX = 0xFEFA3203
CPUID.7.0:EBX = 0xF1BF2FB9
CPUID.7.0:ECX = 0x1A415FE6
CPUID.7.0:EDX = 0x23D14010
CPUID.7.1:EAX = 0x00001C30

XCR0: 0x00000000000600E7

But then also advertises CPUID.1D as 0s -

CPUID.1D.0:EAX = 0x00000000
CPUID.1D.1:EBX = 0x00000000
CPUID.1D.1:ECX = 0x00000000

These 1D leaves are supposed to hold relevant AMX Tile values, and should be 0 for systems NOT supporting AMX.
This mixed-signal CPUID causes lot of issues, like illegal amx instructions

Note - Many instances of EMR platform on windows-2025 show AMX unavailable with CPUID.7 and XCR0 not advertising AMX capabilities. This does not create issues.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 22.04 Arm64
• Ubuntu 24.04
• Ubuntu 24.04 Arm64
• Ubuntu 26.04
• Ubuntu 26.04 Arm64
• Ubuntu Slim
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26
• macOS 26 Arm64
• Windows Server 2022
• Windows Server 2025
• Windows Server 2025 with Visual Studio 2026
• Windows Desktop 11
• Windows Desktop 11 with Visual Studio 2026

Image version and build link

Runner Image 2.336.0
https://github.com/rahulchaphalkar/oneDNN/actions/runs/30509979262/job/90772572537

Is it regression?

no

Expected behavior

non-zero cpuid.1d

Actual behavior

CPUID.1D.0:EAX = 0x00000000
CPUID.1D.1:EBX = 0x00000000
CPUID.1D.1:ECX = 0x00000000

Repro steps

Print out cpuid information for cpuid.7 and cpuid.1d for Intel 5th gen Xeon (INTEL(R) XEON(R) PLATINUM 8573C) EMR

[v-SergeiRadich]

Hi!

We will take a look.

[brhoades]

This reads similar to CI failures that began mid-July on our Intel Windows runners only. We see failures on both windows-2025 and windows-2022. We also see it on the Xeon 8370C too. It's causing an alloc-heavy a Go unit test suite to crash from memory corruption. Runs below contain additional hardware info.

Here's a specific failure:
https://github.com/kolide/launcher/actions/runs/30930997739/job/92131851557

And these contain more examples:

• https://github.com/kolide/launcher/actions/runs/30860321842
• https://github.com/kolide/launcher/actions/runs/30839386953

A few partial stack traces from Go 1.26.5

fatal error: found pointer to free object

runtime stack:
runtime.throw({0x1406314e5?, 0xc000080008?})
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/panic.go:1229 +0x4d fp=0x4751f938 sp=0x4751f908 pc=0x14008aa0d
runtime.(*mspan).reportZombies(0x475800a8)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mgcsweep.go:893 +0x325 fp=0x4751f9b8 sp=0x4751f938 pc=0x14003ac85
runtime.(*sweepLocked).sweep(0x7ffb008aa2fd?, 0x0)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mgcsweep.go:668 +0x6c5 fp=0x4751faf8 sp=0x4751f9b8 pc=0x140039d65
runtime.(*mcentral).uncacheSpan(0x140048a35?, 0x4751fb48?)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mcentral.go:237 +0xb3 fp=0x4751fb20 sp=0x4751faf8 pc=0x140024c13
runtime.(*mcache).releaseAll(0x671b90)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mcache.go:322 +0x12c fp=0x4751fb78 sp=0x4751fb20 pc=0x14002450c
runtime.(*mcache).prepareForSweep(0x671b90)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mcache.go:366 +0x35 fp=0x4751fba0 sp=0x4751fb78 pc=0x140024615

runtime: g66: frame.sp=0xc000297c58 top=0xc000297fe0
    stack=[0xc000296000-0xc000298000
fatal error: traceback did not unwind completely
[signal 0xc0000005 code=0x0 addr=0xe8 pc=0x1400747a5]

runtime stack:
runtime.throw({0x140634760?, 0xc00000d820?})
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/panic.go:1229 +0x4d fp=0x5ffa60 sp=0x5ffa30 pc=0x140086f0d
runtime.sigpanic()
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/signal_windows.go:379 +0x265 fp=0x5ffaa8 sp=0x5ffa60 pc=0x140066ae5
runtime.(*unwinder).next(0x5ffb58)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/traceback.go:459 +0x105 fp=0x5ffb20 sp=0x5ffaa8 pc=0x1400747a5
runtime.scanstack(0xc000044000, 0xc00003f260)
    C:/hostedtoolcache/windows/go/1.26.5/x64/src/runtime/mgcmark.go:972 +0x2d1 fp=0x5ffc38 sp=0x5ffb20 pc=0x14002f5f1
runtime.markroot(0xc00003f260, 0x7, 0x1)

Let me know if this is separate and I'll open another issue.