I work in CPU security and it's the same with microarchitecture. You wanna know if a machine is vulnerable to a certain issue?

- The technical experts (including Intel engineers) will say something like "it affects Blizzard Creek and Windy Bluff models'

- Intel's technical docs will say "if CPUID leaf 0x3aa asserts bit 63 then the CPU is affected". (There is no database for this you can only find it out by actually booting one up).

- The spec sheet for the hardware calls it a "Xeon Osmiridium X36667-IA"

Absolutely none of these forms of naming have any way to correlate between them. They also have different names for the same shit depending on whether it's a consumer or server chip.

Meanwhile, AMD's part numbers contain a digit that increments with each year but is off-by-one with regard to the "Zen" brand version.

Usually I just ask the LLM and accept that it's wrong 20% of the time.

> - Intel's technical docs will say "if CPUID leaf 0x3aa asserts bit 63 then the CPU is affected". (There is no database for this you can only find it out by actually booting one up).

I’m doing some OS work at the moment and running into this. I’m really surprised there’s no caniuse.com for cpu features. I’m planning on requiring support for all the features that have been in every cpu that shipped in the last 10+ years. But it’s basically impossible to figure that out. Especially across Intel and amd. Can I assume apic? Iommu stuff? Is acpi 2 actually available on all CPUs or do I need to have to have support for the old version as well? It’s very annoying.

That's been the case with hardware at several companies I was at.

I was convinced that the process was encouraged by folks who used it as a sort of weird gatekeeping by folks who only used the magic code names.

Even better I worked at a place where they swapped code names between two products at one time... it wasn't without any reason, but it mean that a lot of product documentation suddenly conflicted.

I eventually only refereed to exact part numbers and model numbers and refused to play the code name game. This turned into an amusing situation where some managers who only used code names were suddenly silent as they clearly didn't know the product / part to code name convention.

> AMD's part numbers contain a digit that increments with each year

Aha, but which digit? Sure, that's easy for server, HEDT and desktop (it's the first one) but if you look at their line of laptop chips then it all breaks down.

> Absolutely none of these forms of naming have any way to correlate between them.

I've found that -- as of a ~decade ago, at least, ark.intel.com had a really good way to cross-reference among codenames / SKUs / part numbers / feature set/specs. I've never seen errata there but they might be. Also, I haven't used it in a long time so it could've gotten worse.

Also technically the code names are only for unreleased products so on ark it’ll say “products formerly Ice Lake” but the intel will continue to calm them Ice Lake.

I hear you.

Coincidentally, if anyone knows how to figure out which Intel CPUs actually support 5-level paging / the CPUID flag known as la57, please tell me.

You can correlate microarchitecture to product SKUs using the Intel site that the article links. AMD has a similar site with similar functionality (except that AFAIK it won't let you easily get a list of products with a given uarch). These both have their faults, but I'd certainly pick them over an LLM.

But you're correct that for anything buried in the guts of CPUID, your life is pain. And Intel's product branding has been a disaster for years.

I've also found the same thing a decade ago, apparently lots of features(e.g. specific instruction, igpu) are broadly advertised as belonging to specific arch, but pentium/celeron(or for premium stuff non-xeon) models often lack them entirely and the only way to detect is lscpu/feature bits/digging in UEFI settings.

These have been my go-to for a while now:

https://en.wikipedia.org/wiki/List_of_Intel_Core_processors

https://en.wikipedia.org/wiki/List_of_Intel_Xeon_processors

It doesn't have the CPUID but it's a pretty good mapping of model numbers to code names and on top of that has the rest of the specs.

I have three Ubuntu servers and the naming pisses me off so much. Why can't they just stick with their YY.MM. naming scheme everywhere. Instead, they mostly use code names and I never know what codename I am currently using and what is the latest code name. When I have to upgrade or find a specific Python ppa for whatever OS I am running, I need to research 30 minutes to correlate all these dumb codenames to the actual version numbers.

Same with Intel.

STOP USING CODENAMES. USE NUMBERS!

>"it affects Blizzard Creek and Windy Bluff models'

"Products formerly Blizzard Creek"

WTF does that even mean?

I feel like it's a cultural thing with the designers. Ceragon were the exact same when I used to do microwave links. Happy to provide demo kit, happy to provide sales support, happy to actually come up and go through their product range.

But if you want any deep and complex technical info out of them, like oh maybe how to configure it to fit UK/EU regulatory domain RF rules? Haha no chance.

We ended up hiring a guy fluent in Hebrew just to talk to their support guys.

Super nice kit, but I guess no-one was prepared to pay for an interface layer between the developers and the outside world.

Do you just have banks of old CPUs from every generation to test against?

> Meanwhile, AMD's part numbers contain a digit that increments with each year but is off-by-one with regard to the "Zen" brand version.

Under https://en.wikipedia.org/wiki/Ryzen#Mobile_6 Ryzen 7000 series you could get zen2, zen3, zen3+, zen4

  - sSpec S0ABC                   = "Blizzard Creek" Xeon type 8 version 5 grade 6 getConfig(HT=off, NX=off, ECC=on, VT-x=off, VT-d=on)=4X Stepping B0  
  - "Blizzard Creek" Xeon type 8 -> V3 of Socket FCBGA12345 -> chipset "Pleiades Mounds"   
  - CPUID leaf 0x3aa              = Model specific feature set checks for "Blizzard Creek" and "Windy Bluff(aka Blizzard Creek V2)"  
  - asserts bit 63                = that buggy VT-d circuit is not off  
  - "Xeon Osmiridium X36667-IA"   = marketing name to confuse specifically you(but also IA-36-667 = (S0ABC|S9DFG|S9QWE|QA45P))