Messages in this thread | | | Date | Mon, 31 Jan 2022 19:18:46 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v2 0/6] PPIN (Protected Processor Inventory Number) updates |
| |
On Mon, Jan 31, 2022 at 09:23:20AM -0800, Luck, Tony wrote: > I'm worried that some future thing might reverse that and have > a "package" id for each die in a multi-die package which still > appears as a single node. That would distort the meaning of "package", > so it isn't supposed to happen. But if it did, Linux would be stuck > just reporting one of the "package" ids.
Hmm, so we write that we don't really care about the physical socket in software:
Documentation/x86/topology.rst: "The kernel does not care about the concept of physical sockets because a socket has no relevance to software. It's an electromechanical component. In the past a socket always contained a single package (see below), but with the advent of Multi Chip Modules (MCM) a socket can hold more than one package. So there might be still references to sockets in the code, but they are of historical nature and should be cleaned up."
and the PPIN is a physical socket property. So there's no proper way for us to tie to anything that represents the physical socket.
So, the use case you're imagining would be, what?
The FRU code glue would go:
"I got an MCE on CPU X...
Lemme see which PPIN is it:
# cat /sys/devices/system/cpu/cpuX/topology/ppin BLA
ah ok, lemme report it:
You just had an MCE on CPU X, socket BLA"
Something like that?
But that FRU glue software would have to run as root so that it reads the ppin sysfs file.
But we don't want to expose that processor serial number to !root users so we're forcing the people to run the FRU thing as root.
This feels like this guy here:
https://c.tenor.com/fDZOE4okO3EAAAAC/homer-simpsons.gif
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |