1 /* 2 * This file and its contents are supplied under the terms of the 3 * Common Development and Distribution License ("CDDL"), version 1.0. 4 * You may only use this file in accordance with the terms of version 5 * 1.0 of the CDDL. 6 * 7 * A full copy of the text of the CDDL should have accompanied this 8 * source. A copy of the CDDL is also available via the Internet at 9 * http://www.illumos.org/license/CDDL. 10 */ 11 12 /* 13 * Copyright 2025 Oxide Computer Company 14 */ 15 16 #ifndef _ZEN_UMC_H 17 #define _ZEN_UMC_H 18 19 /* 20 * This file contains definitions that are used to manage and decode the Zen UMC 21 * state. 22 */ 23 24 #ifdef __cplusplus 25 extern "C" { 26 #endif 27 28 #include <sys/stdint.h> 29 #include <sys/sunddi.h> 30 #include <sys/nvpair.h> 31 #include <sys/x86_archext.h> 32 #include <amdzen_client.h> 33 34 /* 35 * This is the maximum number of DRAM rules that we expect any supported device 36 * to have here. The actual number may be less. These are rules that come from a 37 * DF CCM. 38 */ 39 #define ZEN_UMC_MAX_DRAM_RULES 20 40 41 /* 42 * This is the maximum number of rules that we expect any system to actually 43 * have for each UMC. 44 */ 45 #define ZEN_UMC_MAX_CS_RULES 4 46 47 /* 48 * This is the maximum number of DFs that we expect to encounter in a given 49 * platform. This number comes from the Naples generation, where there were up 50 * to 4 per socket, 2 sockets per machine, so 8 total. In subsequent generations 51 * there is only a single 1 per socket. 52 */ 53 #define ZEN_UMC_MAX_DFS 8 54 55 /* 56 * This indicates the maximum number of UMC DF nodes that we expect to 57 * encounter. 58 */ 59 #define ZEN_UMC_MAX_UMCS 12 60 61 /* 62 * This indicates the maximum number of DRAM offset rules that can exist in a 63 * platform. Note, this is directly tied to the maximum number of CS rules. 64 */ 65 #define ZEN_UMC_MAX_DRAM_OFFSET (ZEN_UMC_MAX_CS_RULES - 1) 66 67 /* 68 * This indicates the maximum number of remap rule sets and corresponding 69 * entries that can exist. Milan's max is smaller than the current overall DFv4 70 * maximum. 71 */ 72 #define ZEN_UMC_MAX_CS_REMAPS 4 73 #define ZEN_UMC_MAX_REMAP_ENTS 16 74 #define ZEN_UMC_MILAN_CS_NREMAPS 2 75 #define ZEN_UMC_MILAN_REMAP_ENTS 12 76 #define ZEN_UMC_REMAP_PER_REG 8 77 #define ZEN_UMC_REMAP_PER_REG_4D2 6 78 79 /* 80 * DRAM Channel related maximums. 81 */ 82 #define ZEN_UMC_MAX_DIMMS 2 83 #define ZEN_UMC_MAX_CS_PER_DIMM 2 84 #define ZEN_UMC_MAX_CS_BITS 2 85 #define ZEN_UMC_MAX_CHAN_BASE 2 86 #define ZEN_UMC_MAX_CHAN_MASK 2 87 #define ZEN_UMC_MAX_BANK_BITS 5 88 #define ZEN_UMC_MAX_COL_BITS 16 89 #define ZEN_UMC_MAX_RM_BITS 4 90 #define ZEN_UMC_MAX_COLSEL_PER_REG 8 91 92 #define ZEN_UMC_DDR4_CHAN_NMASKS 1 93 94 /* 95 * DRAM Channel hash maximums. Surprisingly enough, the DDR4 and DDR5 maximums 96 * are the same; however, in exchange what hashes are actually implemented 97 * varies. 98 */ 99 #define ZEN_UMC_MAX_CHAN_BANK_HASH 5 100 #define ZEN_UMC_MAX_CHAN_RM_HASH 3 101 #define ZEN_UMC_MAX_CHAN_CS_HASH 2 102 103 /* 104 * A sentinel to indicate we were unable to determine a frequency or transfer 105 * rate. 106 */ 107 #define ZEN_UMC_UNKNOWN_FREQ 0 108 109 /* 110 * This is the number of memory P-states that the UMC supports. This appears to 111 * be the same across all Zen Family processors. While there are ways to see the 112 * current P-state, it is hard to really know when these transitions occur. We 113 * simply grab all of the speed and configuration information with them when we 114 * discover it. 115 */ 116 #define ZEN_UMC_NMEM_PSTATES 4 117 118 /* 119 * This is the logical set of different channel interleaving rules that we 120 * support today in the driver. The actual values of the enumeration do not 121 * overlap at all with hardware. Do not use these to try and marry up against 122 * values from the DF itself. 123 * 124 * Note, these values are also encoded in the private mc decoder dumps that we 125 * can produce. If these values change, please take care of ensuring 126 * compatibility for others who may be consuming this. Appending to this list 127 * should be OK. 128 */ 129 typedef enum df_chan_ileave { 130 DF_CHAN_ILEAVE_1CH = 0, 131 DF_CHAN_ILEAVE_2CH, 132 DF_CHAN_ILEAVE_4CH, 133 DF_CHAN_ILEAVE_6CH, 134 DF_CHAN_ILEAVE_8CH, 135 DF_CHAN_ILEAVE_16CH, 136 DF_CHAN_ILEAVE_32CH, 137 DF_CHAN_ILEAVE_COD4_2CH, 138 DF_CHAN_ILEAVE_COD2_4CH, 139 DF_CHAN_ILEAVE_COD1_8CH, 140 /* 141 * The primary NPS hashes were added in Zen 4 / DF 4.0. 142 */ 143 DF_CHAN_ILEAVE_NPS4_2CH, 144 DF_CHAN_ILEAVE_NPS2_4CH, 145 DF_CHAN_ILEAVE_NPS1_8CH, 146 DF_CHAN_ILEAVE_NPS4_3CH, 147 DF_CHAN_ILEAVE_NPS2_6CH, 148 DF_CHAN_ILEAVE_NPS1_12CH, 149 DF_CHAN_ILEAVE_NPS2_5CH, 150 DF_CHAN_ILEAVE_NPS1_10CH, 151 /* 152 * The 1K/2K split was primarily introduced in Zen 5. There are no DF 153 * 4.0 style NPS values in the enumeration. 154 */ 155 DF_CHAN_ILEAVE_NPS4_2CH_1K, 156 DF_CHAN_ILEAVE_NPS2_4CH_1K, 157 DF_CHAN_ILEAVE_NPS1_8CH_1K, 158 DF_CHAN_ILEAVE_NPS1_16CH_1K, 159 DF_CHAN_ILEAVE_NPS4_3CH_1K, 160 DF_CHAN_ILEAVE_NPS2_6CH_1K, 161 DF_CHAN_ILEAVE_NPS1_12CH_1K, 162 DF_CHAN_ILEAVE_NPS0_24CH_1K, 163 DF_CHAN_ILEAVE_NPS2_5CH_1K, 164 DF_CHAN_ILEAVE_NPS1_10CH_1K, 165 DF_CHAN_ILEAVE_NPS4_2CH_2K, 166 DF_CHAN_ILEAVE_NPS2_4CH_2K, 167 DF_CHAN_ILEAVE_NPS1_8CH_2K, 168 DF_CHAN_ILEAVE_NPS1_16CH_2K, 169 DF_CHAN_ILEAVE_NPS4_3CH_2K, 170 DF_CHAN_ILEAVE_NPS2_6CH_2K, 171 DF_CHAN_ILEAVE_NPS1_12CH_2K, 172 DF_CHAN_ILEAVE_NPS0_24CH_2K, 173 DF_CHAN_ILEAVE_NPS2_5CH_2K, 174 DF_CHAN_ILEAVE_NPS1_10CH_2K, 175 /* 176 * MI300 style hash variants. Internally referred to as "MI3H". 177 */ 178 DF_CHAN_ILEAVE_MI3H_8CH, 179 DF_CHAN_ILEAVE_MI3H_16CH, 180 DF_CHAN_ILEAVE_MI3H_32CH 181 } df_chan_ileave_t; 182 183 /* 184 * This is a collection of logical flags that we use to cover attributes of a 185 * DRAM rule. 186 */ 187 typedef enum df_dram_flags { 188 /* 189 * Used to indicate that the contents of the rule are actually valid and 190 * should be considered. Many rules can be unused in hardware. 191 */ 192 DF_DRAM_F_VALID = 1 << 0, 193 /* 194 * Indicates that the DRAM hole is active for this particular rule. If 195 * this flag is set and the hole is valid in the DF, then we need to 196 * take the actual DRAM hole into account. 197 */ 198 DF_DRAM_F_HOLE = 1 << 1, 199 /* 200 * These next five are used to indicate when hashing is going on, which 201 * bits to use. These are for 4K, 64K, 2M, 1G, and 1T parts of addresses 202 * respectively. The 4K and 1T were added starting with DF 4D2. The 4K 203 * hashing is only currently known to be consumed as part of the MI3H 204 * series hashed interleaving. 205 */ 206 DF_DRAM_F_HASH_12_14 = 1 << 2, 207 DF_DRAM_F_HASH_16_18 = 1 << 3, 208 DF_DRAM_F_HASH_21_23 = 1 << 4, 209 DF_DRAM_F_HASH_30_32 = 1 << 5, 210 DF_DRAM_F_HASH_40_42 = 1 << 6, 211 /* 212 * Indicates that this rule should have remap processing and the remap 213 * target is valid. If the DF_DRAM_F_REMAP_SOCK flag is set, this 214 * indicates that the processing is based on socket versus a particular 215 * entry. 216 */ 217 DF_DRAM_F_REMAP_EN = 1 << 7, 218 DF_DRAM_F_REMAP_SOCK = 1 << 8, 219 /* 220 * Indicates that this region is backed by "storage class memory". 221 * Maintained for debugging information. 222 */ 223 DF_DRAM_F_SCM = 1 << 9 224 } df_dram_flags_t; 225 226 /* 227 * This represents a single offset value for a channel. This is used when 228 * applying normalization. 229 */ 230 typedef struct chan_offset { 231 uint32_t cho_raw; 232 boolean_t cho_valid; 233 uint64_t cho_offset; 234 } chan_offset_t; 235 236 /* 237 * This structure represents a single DRAM rule, no matter where it shows up. 238 * This smooths over the differences between generations. 239 */ 240 typedef struct df_dram_rule { 241 uint32_t ddr_raw_base; 242 uint32_t ddr_raw_limit; 243 uint32_t ddr_raw_ctrl; 244 uint32_t ddr_raw_ileave; 245 df_dram_flags_t ddr_flags; 246 uint64_t ddr_base; 247 uint64_t ddr_limit; 248 uint16_t ddr_dest_fabid; 249 uint8_t ddr_sock_ileave_bits; 250 uint8_t ddr_die_ileave_bits; 251 uint8_t ddr_addr_start; 252 uint8_t ddr_remap_ent; 253 df_chan_ileave_t ddr_chan_ileave; 254 } df_dram_rule_t; 255 256 typedef struct umc_dimm_base { 257 uint64_t udb_base; 258 boolean_t udb_valid; 259 } umc_dimm_base_t; 260 261 typedef enum umc_dimm_type { 262 UMC_DIMM_T_UNKNOWN, 263 UMC_DIMM_T_DDR4, 264 UMC_DIMM_T_LPDDR4, 265 UMC_DIMM_T_DDR5, 266 UMC_DIMM_T_LPDDR5 267 } umc_dimm_type_t; 268 269 typedef enum umc_dimm_width { 270 UMC_DIMM_W_X4, 271 UMC_DIMM_W_X8, 272 UMC_DIMM_W_X16, 273 } umc_dimm_width_t; 274 275 typedef enum umc_dimm_kind { 276 UMC_DIMM_K_UDIMM, 277 UMC_DIMM_K_RDIMM, 278 UMC_DIMM_K_LRDIMM, 279 UMC_DIMM_K_3DS_RDIMM 280 } umc_dimm_kind_t; 281 282 typedef enum umc_dimm_flags { 283 /* 284 * This flag indicates that this DIMM should be used for decoding 285 * purposes. It basically means that there is at least one chip-select 286 * decoding register that has been enabled. Unfortunately, we don't have 287 * a good way right now of distinguishing between a DIMM being present 288 * and being usable. This likely needs to be re-evaluated when we 289 * consider how we present things to topo. We may be able to pull this 290 * out of the clock disable logic. 291 */ 292 UMC_DIMM_F_VALID = 1 << 0, 293 } umc_dimm_flags_t; 294 295 typedef enum umc_cs_flags { 296 /* 297 * This flag indicates that at least one of the base or secondary 298 * chip-select decoding register is enabled. 299 */ 300 UMC_CS_F_DECODE_EN = 1 << 0, 301 } umc_cs_flags_t; 302 303 /* 304 * A DIMM may have one or more ranks, which is an independent logical item that 305 * is activated by a 'chip-select' signal on a DIMM (e.g. CS_L[1:0]). In a given 306 * channel, AMD always has two instances of a 'chip-select' data structure. 307 * While these have a 1:1 correspondence in the case of single and dual rank 308 * DIMMs, in the case where there are more, then rank multiplication rules are 309 * used to determine which of the additional chip and chip-select signals to 310 * actually drive on the bus. But still, there are only up to two of these 311 * structures. To match AMD terminology we call these a 'chip-select' or 312 * 'umc_cs_t'. 313 * 314 * The amount of information that exists on a per-chip-select and per-DIMM basis 315 * varies between the different memory controller generations. As such, we 316 * normalize things such that a given chip-select always has all of the 317 * information related to it, duplicating it in the DDR4 case. 318 * 319 * While DDR5 adds the notion of sub-channels, a single chip-select is used to 320 * cover both sub-channels and instead a bit in the normalized address (and 321 * hashing) is used to determine which sub-channel to active. So while hardware 322 * actually has different chip-select lines for each sub-channel they are not 323 * represented that way in the UMC. 324 */ 325 typedef struct umc_cs { 326 umc_cs_flags_t ucs_flags; 327 umc_dimm_base_t ucs_base; 328 umc_dimm_base_t ucs_sec; 329 uint64_t ucs_base_mask; 330 uint64_t ucs_sec_mask; 331 uint8_t ucs_nbanks; 332 uint8_t ucs_ncol; 333 uint8_t ucs_nrow_lo; 334 uint8_t ucs_nrow_hi; 335 uint8_t ucs_nrm; 336 uint8_t ucs_nbank_groups; 337 uint8_t ucs_cs_xor; 338 uint8_t ucs_row_hi_bit; 339 uint8_t ucs_row_low_bit; 340 uint8_t ucs_bank_bits[ZEN_UMC_MAX_BANK_BITS]; 341 uint8_t ucs_col_bits[ZEN_UMC_MAX_COL_BITS]; 342 uint8_t ucs_inv_msbs; 343 uint8_t ucs_rm_bits[ZEN_UMC_MAX_RM_BITS]; 344 uint8_t ucs_inv_msbs_sec; 345 uint8_t ucs_rm_bits_sec[ZEN_UMC_MAX_RM_BITS]; 346 uint8_t ucs_subchan; 347 } umc_cs_t; 348 349 /* 350 * This structure represents information about a DIMM. Most of the interesting 351 * stuff is on the umc_cs_t up above, which is the logical 'chip-select' that 352 * AMD implements in the UMC. 353 * 354 * When we come back and add topo glue for the driver, we should consider adding 355 * the following information here and in the channel: 356 * 357 * o Channel capable speed 358 * o A way to map this DIMM to an SMBIOS / SPD style entry 359 */ 360 typedef struct umc_dimm { 361 umc_dimm_flags_t ud_flags; 362 umc_dimm_width_t ud_width; 363 umc_dimm_kind_t ud_kind; 364 uint32_t ud_dimmno; 365 uint32_t ud_dimmcfg_raw; 366 uint64_t ud_dimm_size; 367 umc_cs_t ud_cs[ZEN_UMC_MAX_CS_PER_DIMM]; 368 } umc_dimm_t; 369 370 typedef enum umc_chan_flags { 371 /* 372 * Indicates that the channel has enabled ECC logic. 373 */ 374 UMC_CHAN_F_ECC_EN = 1 << 0, 375 /* 376 * We believe that this indicates some amount of the AMD SEV encryption 377 * is ongoing, leveraging some of the page-table control. 378 */ 379 UMC_CHAN_F_ENCR_EN = 1 << 1, 380 /* 381 * Indicates that the channel is employing data scrambling. This is 382 * basically what folks have called Transparent Shared Memory 383 * Encryption. 384 */ 385 UMC_CHAN_F_SCRAMBLE_EN = 1 << 2 386 } umc_chan_flags_t; 387 388 typedef struct umc_bank_hash { 389 uint32_t ubh_row_xor; 390 uint32_t ubh_col_xor; 391 boolean_t ubh_en; 392 } umc_bank_hash_t; 393 394 typedef struct umc_addr_hash { 395 uint64_t uah_addr_xor; 396 boolean_t uah_en; 397 } umc_addr_hash_t; 398 399 typedef struct umc_pc_hash { 400 uint32_t uph_row_xor; 401 uint32_t uph_col_xor; 402 uint8_t uph_bank_xor; 403 boolean_t uph_en; 404 } umc_pc_hash_t; 405 406 typedef enum umc_chan_hash_flags { 407 UMC_CHAN_HASH_F_BANK = 1 << 0, 408 UMC_CHAN_HASH_F_RM = 1 << 1, 409 UMC_CHAN_HASH_F_PC = 1 << 2, 410 UMC_CHAN_HASH_F_CS = 1 << 3, 411 } umc_chan_hash_flags_t; 412 413 typedef struct umc_chan_hash { 414 umc_chan_hash_flags_t uch_flags; 415 umc_bank_hash_t uch_bank_hashes[ZEN_UMC_MAX_CHAN_BANK_HASH]; 416 umc_addr_hash_t uch_rm_hashes[ZEN_UMC_MAX_CHAN_RM_HASH]; 417 umc_addr_hash_t uch_cs_hashes[ZEN_UMC_MAX_CHAN_CS_HASH]; 418 umc_pc_hash_t uch_pc_hash; 419 } umc_chan_hash_t; 420 421 /* 422 * This structure represents the overall memory channel. There is a 1:1 423 * relationship between these structures and discover UMC hardware entities on 424 * the data fabric. Note, these always exist regardless of whether the channels 425 * are actually implemented on a PCB or not. 426 */ 427 typedef struct zen_umc_chan { 428 umc_chan_flags_t chan_flags; 429 uint32_t chan_fabid; 430 uint32_t chan_instid; 431 uint32_t chan_logid; 432 uint32_t chan_nrules; 433 uint32_t chan_umccfg_raw; 434 uint32_t chan_datactl_raw; 435 uint32_t chan_eccctl_raw; 436 uint32_t chan_umccap_raw; 437 uint32_t chan_umccap_hi_raw; 438 uint32_t chan_np2_raw; 439 uint32_t chan_np2_space0; 440 /* 441 * These have the clock and speed of the channel in MHz and MT/s 442 * respectively. These are not always a 1:2 ratio. See the definition 443 * and discussion around D_UMC_DRAMCFG. Note, the channel's speed may 444 * not be the maximum supported speed of a DIMM itself. That requires 445 * going into the SPD data on Zen, the UMC doesn't track it because it 446 * doesn't matter to it. There is one of these for each memory P-state. 447 */ 448 uint32_t chan_dramcfg_raw[ZEN_UMC_NMEM_PSTATES]; 449 uint32_t chan_clock[ZEN_UMC_NMEM_PSTATES]; 450 uint32_t chan_speed[ZEN_UMC_NMEM_PSTATES]; 451 umc_dimm_type_t chan_type; 452 df_dram_rule_t chan_rules[ZEN_UMC_MAX_CS_RULES]; 453 chan_offset_t chan_offsets[ZEN_UMC_MAX_DRAM_OFFSET]; 454 umc_dimm_t chan_dimms[ZEN_UMC_MAX_DIMMS]; 455 umc_chan_hash_t chan_hash; 456 } zen_umc_chan_t; 457 458 typedef struct zen_umc_cs_remap { 459 uint_t csr_nremaps; 460 uint16_t csr_remaps[ZEN_UMC_MAX_REMAP_ENTS]; 461 } zen_umc_cs_remap_t; 462 463 typedef enum zen_umc_df_flags { 464 /* 465 * Indicates that the DRAM Hole is valid and in use. 466 */ 467 ZEN_UMC_DF_F_HOLE_VALID = 1 << 0, 468 /* 469 * These next three are used to indicate when hashing is going on, which 470 * bits to use. These are for 64K, 2M, and 1G parts of addresses 471 * respectively. 472 */ 473 ZEN_UMC_DF_F_HASH_16_18 = 1 << 1, 474 ZEN_UMC_DF_F_HASH_21_23 = 1 << 2, 475 ZEN_UMC_DF_F_HASH_30_32 = 1 << 3 476 } zen_umc_df_flags_t; 477 478 typedef struct zen_umc_df { 479 zen_umc_df_flags_t zud_flags; 480 uint_t zud_dfno; 481 uint_t zud_ccm_inst; 482 uint_t zud_dram_nrules; 483 uint_t zud_nchan; 484 uint_t zud_cs_nremap; 485 uint32_t zud_capab; 486 uint32_t zud_hole_raw; 487 uint32_t zud_glob_ctl_raw; 488 uint64_t zud_hole_base; 489 df_dram_rule_t zud_rules[ZEN_UMC_MAX_DRAM_RULES]; 490 zen_umc_cs_remap_t zud_remap[ZEN_UMC_MAX_CS_REMAPS]; 491 zen_umc_chan_t zud_chan[ZEN_UMC_MAX_UMCS]; 492 } zen_umc_df_t; 493 494 typedef enum zen_umc_umc_style { 495 /* 496 * These are UMCs that generally implement the basic DDR4 UMC found in 497 * Zen 1-3 systems. The APU variant does not support multiple banks. 498 */ 499 ZEN_UMC_UMC_S_DDR4, 500 ZEN_UMC_UMC_S_DDR4_APU, 501 /* 502 * This represents a slightly different UMC design that exists in Van 503 * Gogh and Mendocino. In particular, it primarily supports LPDDR5 but 504 * is an extension of the DDR4 UMC in some respects such as the 505 * DramConfiguration register, but otherwise looks more like the DDR5 506 * case. 507 */ 508 ZEN_UMC_UMC_S_HYBRID_LPDDR5, 509 /* 510 * These are UMCs that generally implement the basic DDR5 UMC found in 511 * Zen 4+ (and other) systems. The APU variant does not support multiple 512 * banks. 513 */ 514 ZEN_UMC_UMC_S_DDR5, 515 ZEN_UMC_UMC_S_DDR5_APU 516 } zen_umc_umc_style_t; 517 518 typedef enum zen_umc_fam_flags { 519 /* 520 * Indicates that there's an indirection table for the destinations of 521 * target rules. This is only required to be set explicitly for systems 522 * prior to the DF 4D2 variant as after that remapping support is 523 * indicated in the DF::DfCapability register. 524 */ 525 ZEN_UMC_FAM_F_TARG_REMAP = 1 << 0, 526 /* 527 * Indicates that non-power of two interleave rules are supported and 528 * that we need additional register configuration. 529 */ 530 ZEN_UMC_FAM_F_NP2 = 1 << 1, 531 /* 532 * Indicates that the DF hashing rules to configure COD hashes need to 533 * be checked. 534 */ 535 ZEN_UMC_FAM_F_NORM_HASH = 1 << 2, 536 /* 537 * In DDR4 this indicates presence of the HashRM and in DDR5 the 538 * AddrHash. 539 */ 540 ZEN_UMC_FAM_F_UMC_HASH = 1 << 3, 541 /* 542 * Indicates support for extended UMC registers for larger addresses. 543 * Generally on Server parts. This should only be set if there are 544 * non-reserved bits in the register. 545 */ 546 ZEN_UMC_FAM_F_UMC_EADDR = 1 << 4, 547 /* 548 * Indicates that CS decoder supports an XOR function. 549 */ 550 ZEN_UMC_FAM_F_CS_XOR = 1 << 5 551 } zen_umc_fam_flags_t; 552 553 /* 554 * This structure is meant to contain per SoC family (not CPUID family) 555 * information. This is stuff that we basically need to encode about the 556 * processor itself and relates to its limits, the style it operates in, the 557 * way it works, etc. 558 */ 559 typedef struct zen_umc_fam_data { 560 x86_processor_family_t zufd_family; 561 zen_umc_fam_flags_t zufd_flags; 562 uint8_t zufd_dram_nrules; 563 uint8_t zufd_cs_nrules; 564 zen_umc_umc_style_t zufd_umc_style; 565 umc_chan_hash_flags_t zufd_chan_hash; 566 uint32_t zufd_base_instid; 567 } zen_umc_fam_data_t; 568 569 /* 570 * The top-level data structure for the system. This is a single structure that 571 * represents everything that could possibly exist and is filled in with what we 572 * actually discover. 573 */ 574 typedef struct zen_umc { 575 uint64_t umc_tom; 576 uint64_t umc_tom2; 577 dev_info_t *umc_dip; 578 x86_processor_family_t umc_family; 579 df_rev_t umc_df_rev; 580 const zen_umc_fam_data_t *umc_fdata; 581 df_fabric_decomp_t umc_decomp; 582 uint_t umc_ndfs; 583 zen_umc_df_t umc_dfs[ZEN_UMC_MAX_DFS]; 584 /* 585 * This lock protects the data underneath here. 586 */ 587 kmutex_t umc_nvl_lock; 588 nvlist_t *umc_decoder_nvl; 589 char *umc_decoder_buf; 590 size_t umc_decoder_len; 591 } zen_umc_t; 592 593 typedef enum zen_umc_decode_failure { 594 ZEN_UMC_DECODE_F_NONE = 0, 595 /* 596 * Indicates that the address was not contained within the TOM and TOM2 597 * regions that indicate DRAM (or was in a reserved hole). 598 */ 599 ZEN_UMC_DECODE_F_OUTSIDE_DRAM, 600 /* 601 * Indicates that we could not find a DF rule in the CCM rule that 602 * claims to honor this address. 603 */ 604 ZEN_UMC_DECODE_F_NO_DF_RULE, 605 /* 606 * Indicates that trying to construct the interleave address to use 607 * would have led to an underflow somehow. 608 */ 609 ZEN_UMC_DECODE_F_ILEAVE_UNDERFLOW, 610 /* 611 * Indicates that we do not currently support decoding the indicated 612 * channel interleave type. 613 */ 614 ZEN_UMC_DECODE_F_CHAN_ILEAVE_NOTSUP, 615 /* 616 * Indicates that we found a COD hash rule that had a non-zero socket or 617 * die interleave, which isn't supported and we don't know how to 618 * decode. 619 */ 620 ZEN_UMC_DECODE_F_COD_BAD_ILEAVE, 621 /* 622 * This is similar to the above, but indicates that we hit a bad NPS 623 * interleave rule instead of a COD. 624 */ 625 ZEN_UMC_DECODE_F_NPS_BAD_ILEAVE, 626 /* 627 * Indicates that somehow we thought we should use a remap rule set that 628 * was beyond our capabilities. 629 */ 630 ZEN_UMC_DECODE_F_BAD_REMAP_SET, 631 /* 632 * Indicates that we tried to find an index for the remap rules; 633 * however, the logical component ID was outside the range of the number 634 * of entries that we have. 635 */ 636 ZEN_UMC_DECODE_F_BAD_REMAP_ENTRY, 637 /* 638 * Indicates that the remap rule had an invalid component bit set in its 639 * mask. 640 */ 641 ZEN_UMC_DECODE_F_REMAP_HAS_BAD_COMP, 642 /* 643 * Indicates that we could not find a UMC with the fabric ID we thought 644 * we should have. 645 */ 646 ZEN_UMC_DECODE_F_CANNOT_MAP_FABID, 647 /* 648 * Indicates that somehow the UMC we found did not actually contain a 649 * DRAM rule that covered our original PA. 650 */ 651 ZEN_UMC_DECODE_F_UMC_DOESNT_HAVE_PA, 652 /* 653 * Indicates that we would have somehow underflowed the address 654 * calculations normalizing the system address. 655 */ 656 ZEN_UMC_DECODE_F_CALC_NORM_UNDERFLOW, 657 /* 658 * Indicates that none of the UMC's chip-selects actually matched a base 659 * or secondary. 660 */ 661 ZEN_UMC_DECODE_F_NO_CS_BASE_MATCH, 662 } zen_umc_decode_failure_t; 663 664 /* 665 * This struct accumulates all of our decoding logic and states and we use it so 666 * it's easier for us to look at what's going on and the decisions that we made 667 * along the way. 668 */ 669 typedef struct zen_umc_decoder { 670 zen_umc_decode_failure_t dec_fail; 671 uint64_t dec_fail_data; 672 uint64_t dec_pa; 673 const zen_umc_df_t *dec_df_rulesrc; 674 uint32_t dec_df_ruleno; 675 const df_dram_rule_t *dec_df_rule; 676 uint64_t dec_ilv_pa; 677 /* 678 * These three values represent the IDs that we extract from the 679 * interleave address. 680 */ 681 uint32_t dec_ilv_sock; 682 uint32_t dec_ilv_die; 683 uint32_t dec_ilv_chan; 684 uint32_t dec_ilv_fabid; 685 uint32_t dec_log_fabid; 686 uint32_t dec_remap_comp; 687 uint32_t dec_targ_fabid; 688 const zen_umc_chan_t *dec_umc_chan; 689 uint32_t dec_umc_ruleno; 690 uint64_t dec_norm_addr; 691 const umc_dimm_t *dec_dimm; 692 const umc_cs_t *dec_cs; 693 boolean_t dec_cs_sec; 694 uint32_t dec_dimm_col; 695 uint32_t dec_dimm_row; 696 uint8_t dec_log_csno; 697 uint8_t dec_dimm_bank; 698 uint8_t dec_dimm_bank_group; 699 uint8_t dec_dimm_subchan; 700 uint8_t dec_dimm_rm; 701 uint8_t dec_chan_csno; 702 uint8_t dec_dimm_no; 703 uint8_t dec_dimm_csno; 704 } zen_umc_decoder_t; 705 706 /* 707 * Decoding and normalization routines. 708 */ 709 extern boolean_t zen_umc_decode_pa(const zen_umc_t *, const uint64_t, 710 zen_umc_decoder_t *); 711 712 /* 713 * Encoding and decoding 714 */ 715 extern nvlist_t *zen_umc_dump_decoder(zen_umc_t *); 716 extern boolean_t zen_umc_restore_decoder(nvlist_t *, zen_umc_t *); 717 718 #ifdef __cplusplus 719 } 720 #endif 721 722 #endif /* _ZEN_UMC_H */ 723