extend AMD chiprev mechanism to identify core revs
With #14834 and #14835 behind us, the last thing we need in order to usefully initialise the CCX on oxide machines is more detailed identifying information about the processor we're running on. Currently, generic code has the concept of a chiprev, which maps bits from very Intel-ish cpuid bits (manufacturer, family, model, stepping) onto the somewhat more industry-standard make/model/revision scheme AMD use. This is how we figure out that a particular processor is e.g. a Milan B1 (it does not tell us the actual SKU or OPN, which depends on the number and organisation of internal components). We'll need this information in deciding how to set up various CCX bits.
Unfortunately, that's not enough. We also need to know the silicon revision level of the cores on those CCXs. While a given product revision should always have (so far as I know, anyway) cores of the same generation and revision, the mapping is not 1-1; many different products contain cores of a given generation and revision (e.g., Zen3 B0). The collection of useful MSRs (and non-MSR CCX registers as well, all of which are non-architectural) available on a given processor, and the separate list of bits that must be set or cleared in each, are the union of those that depend upon:
- the processor type (e.g., Milan)
- the processor type and revision (e.g., Milan B1)
- the core generation (e.g., Zen3)
- the core generation and revision (e.g., Zen3 B0)
- a combination of a processor identity (type or type+revision) and core identity (gen or gen+revision)
So to set up the CCX properly we need the core details in the chiprev, and access to it from outside the cpuid subsystem as we already have for the existing chiprev. We also need somewhat better detail about the processor itself, too, and we aren't alone in that: see
amdzen_c_family() for an example of another consumer. While on i86pc most of the CCX setup is assumed to be done by a BIOS, the general facility for identifying processors and cores at this level of detail is therefore generic and we should assume there will be other consumers that may or may not be oxide-specific. While this is considerably more complicated than the previous two prequel episodes, it too should be reasonably easy to integrate upstream, and the presence of an existing consumer -- indeed, we want to reuse part of the implementation -- should make it easier to understand in the absence of the oxide arch code.
The hardest part here is not writing the code but finding terminology that works; things like family, model, stepping, and revision have too many conflicting uses and there are only so many synonyms we can invent.
Updated by Robert Mustacchi about 2 months ago
To test this we've done a number of different things:
- We've booted up various AMD Systems and confirmed that we have properly identified their revisions. This includes current systems like Zen 2 and Zen 3 server systems, Oxide specific systems, forthcoming AMD systems, and much older systems like Family 0x10. For all of these, we used mdb -k to confirm various parts of the revision and related.
- Checked the zen_umc driver on the Zen 2 and Zen 3 systems.
- Confirmed Zen 2 systems see performance counters (there was no change here)
Separately, I've been doing additional development while ensuring that this is present on both stock bits and we have downstream on the Oxide arch.
Updated by Electric Monk about 1 month ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 22e4c3ac083467e1e6241dedfea03e25c101eedf Author: Keith M Wesolowski <email@example.com> Date: 2022-08-24T15:26:51.000Z 14836 extend AMD chiprev mechanism to identify core revs Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Approved by: Joshua M. Clulow <email@example.com>