x86 opcode/CPUID/MSR allocations

[Jiang, Haochen]

> From: Christian Ludloff <ludloff@gmail.com>
> Sent: Wednesday, October 15, 2025 5:09 AM
> 
> If x86 opcode/CPUID/MSR allocations are not
> of your concern, then you can stop reading.
> 
> -------------------- 8< -------------------
> 
> I was asked to relay this to binutils/LKML.
> 
> As of 2025, the following are in active use
> by a corporate entity other than Intel/AMD.
> 
> Any collisions with them should be avoided.
> 
> - opcode 0Eh in PM64 - x86 PUSH CS that got
>   removed by x86-64 in 2002; not used since
> 
> - opcode 0Fh,36h and opcode 0Fh,3Eh - there
>   is a historic collision with Cyrix RDSHR,
>   but that is not considered to be an issue
> 
> - opcode 0Fh,3Ah,E0h...EFh in classic, VEX,
>   EVEX, Map3, and Map7 encodings, without a
>   prefix, or CS/SS/DS/ES/FS/GS, LOCK, REPE/
>   REPNE, or ASIZE/OSIZE/REX (but not REX2!)
>   prefixes - a historic collision with K10M
>   VCVTFXPNTPD2DQ (at MVEX opcode E6h prefix
>   F2) exists but is not considered an issue
> 
> - opcode 0Fh,1Eh,/0 - a "hinting NOP" group
> 
> - CPUID range E000_xxxxh - unspecified leaf
>   return values at this particular time
> 
> - MSR range E000_xxxxh - unspecified values
>   after RESET - unchanged values after INIT
> 
> I have documented them at www.sandpile.org.
> 
> -------------------- 8< -------------------
> 

I have forwarded this mail to my colleagues in case
there is any mismatch.

Thx,
Haochen