Hello!
I have been recently looking into one of the cpuid tools (Todd Allen's Tools: cpuid) to get a better idea on how CPUID instruction works and what kind of data it can yield. What got my attention while browsing through cpuid.c (referencing source files in case someone would like to look into it. ) code, was the way how the cpu's serial number is returned.
From the code it seems to consist of dword returned in EAX register (after CPUID executed with EAX == 1) and dwords from ECX and EDX (after CPUID executed with EAX == 3) - val_1_eax is kept in the stash struct, which hold EAX contents after CPUID(1) was executed and then it's referenced while CPUID(3) is processed. So it looks something like this:
# cpuid -1k | grep "processor serial number:"
processor serial number: 0002-06A7-0000-0000-0000-0000
# hexdump -s16 -n16 -v -C /dev/cpu/0/cpuid
00000010 a7 06 02 00 00 08 10 00 ff e3 ba 1f ff fb eb bf |................|
00000020
# hexdump -s$((16*3)) -n16 -v -C /dev/cpu/0/cpuid
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
Now, the fun part is that my cpu doesn't actually support PSN (its bit is not set in EDX register after CPUID(1) executes), so according to "Table 3-8. Information Returned by CPUID Instruction" from "Intel® 64 and IA-32 Architectures Software Developer’s Manual" it shouldn't be even looked up (if I understand the note correctly that is), but regardless, based on the same table, Serial Number should be a 96-bit value, bits 0-31 set in ECX, bits 32-63 set in EDX, but there's no note where remaining 32-bits should come from (should they be set to 0 or something? ), so here is my question:
How PSN, if supported, should be looked up? And if it's the way how the above tool does it, I would appreciate some gentle explanation on why that's the case.