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 2024 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 /* 296 * A DIMM may have one or more ranks, which is an independent logical item that 297 * is activated by a 'chip-select' signal on a DIMM (e.g. CS_L[1:0]). In a given 298 * channel, AMD always has two instances of a 'chip-select' data structure. 299 * While these have a 1:1 correspondence in the case of single and dual rank 300 * DIMMs, in the case where there are more, then rank multiplication rules are 301 * used to determine which of the additional chip and chip-select signals to 302 * actually drive on the bus. But still, there are only up to two of these 303 * structures. To match AMD terminology we call these a 'chip-select' or 304 * 'umc_cs_t'. 305 * 306 * The amount of information that exists on a per-chip-select and per-DIMM basis 307 * varies between the different memory controller generations. As such, we 308 * normalize things such that a given chip-select always has all of the 309 * information related to it, duplicating it in the DDR4 case. 310 * 311 * While DDR5 adds the notion of sub-channels, a single chip-select is used to 312 * cover both sub-channels and instead a bit in the normalized address (and 313 * hashing) is used to determine which sub-channel to active. So while hardware 314 * actually has different chip-select lines for each sub-channel they are not 315 * represented that way in the UMC. 316 */ 317 typedef struct umc_cs { 318 umc_dimm_base_t ucs_base; 319 umc_dimm_base_t ucs_sec; 320 uint64_t ucs_base_mask; 321 uint64_t ucs_sec_mask; 322 uint8_t ucs_nbanks; 323 uint8_t ucs_ncol; 324 uint8_t ucs_nrow_lo; 325 uint8_t ucs_nrow_hi; 326 uint8_t ucs_nrm; 327 uint8_t ucs_nbank_groups; 328 uint8_t ucs_cs_xor; 329 uint8_t ucs_row_hi_bit; 330 uint8_t ucs_row_low_bit; 331 uint8_t ucs_bank_bits[ZEN_UMC_MAX_BANK_BITS]; 332 uint8_t ucs_col_bits[ZEN_UMC_MAX_COL_BITS]; 333 uint8_t ucs_inv_msbs; 334 uint8_t ucs_rm_bits[ZEN_UMC_MAX_RM_BITS]; 335 uint8_t ucs_inv_msbs_sec; 336 uint8_t ucs_rm_bits_sec[ZEN_UMC_MAX_RM_BITS]; 337 uint8_t ucs_subchan; 338 } umc_cs_t; 339 340 /* 341 * This structure represents information about a DIMM. Most of the interesting 342 * stuff is on the umc_cs_t up above, which is the logical 'chip-select' that 343 * AMD implements in the UMC. 344 * 345 * When we come back and add topo glue for the driver, we should consider adding 346 * the following information here and in the channel: 347 * 348 * o Channel capable speed 349 * o A way to map this DIMM to an SMBIOS / SPD style entry 350 */ 351 typedef struct umc_dimm { 352 umc_dimm_flags_t ud_flags; 353 umc_dimm_width_t ud_width; 354 umc_dimm_kind_t ud_kind; 355 uint32_t ud_dimmno; 356 uint32_t ud_dimmcfg_raw; 357 uint64_t ud_dimm_size; 358 umc_cs_t ud_cs[ZEN_UMC_MAX_CS_PER_DIMM]; 359 } umc_dimm_t; 360 361 typedef enum umc_chan_flags { 362 /* 363 * Indicates that the channel has enabled ECC logic. 364 */ 365 UMC_CHAN_F_ECC_EN = 1 << 0, 366 /* 367 * We believe that this indicates some amount of the AMD SEV encryption 368 * is ongoing, leveraging some of the page-table control. 369 */ 370 UMC_CHAN_F_ENCR_EN = 1 << 1, 371 /* 372 * Indicates that the channel is employing data scrambling. This is 373 * basically what folks have called Transparent Shared Memory 374 * Encryption. 375 */ 376 UMC_CHAN_F_SCRAMBLE_EN = 1 << 2 377 } umc_chan_flags_t; 378 379 typedef struct umc_bank_hash { 380 uint32_t ubh_row_xor; 381 uint32_t ubh_col_xor; 382 boolean_t ubh_en; 383 } umc_bank_hash_t; 384 385 typedef struct umc_addr_hash { 386 uint64_t uah_addr_xor; 387 boolean_t uah_en; 388 } umc_addr_hash_t; 389 390 typedef struct umc_pc_hash { 391 uint32_t uph_row_xor; 392 uint32_t uph_col_xor; 393 uint8_t uph_bank_xor; 394 boolean_t uph_en; 395 } umc_pc_hash_t; 396 397 typedef enum umc_chan_hash_flags { 398 UMC_CHAN_HASH_F_BANK = 1 << 0, 399 UMC_CHAN_HASH_F_RM = 1 << 1, 400 UMC_CHAN_HASH_F_PC = 1 << 2, 401 UMC_CHAN_HASH_F_CS = 1 << 3, 402 } umc_chan_hash_flags_t; 403 404 typedef struct umc_chan_hash { 405 umc_chan_hash_flags_t uch_flags; 406 umc_bank_hash_t uch_bank_hashes[ZEN_UMC_MAX_CHAN_BANK_HASH]; 407 umc_addr_hash_t uch_rm_hashes[ZEN_UMC_MAX_CHAN_RM_HASH]; 408 umc_addr_hash_t uch_cs_hashes[ZEN_UMC_MAX_CHAN_CS_HASH]; 409 umc_pc_hash_t uch_pc_hash; 410 } umc_chan_hash_t; 411 412 /* 413 * This structure represents the overall memory channel. There is a 1:1 414 * relationship between these structures and discover UMC hardware entities on 415 * the data fabric. Note, these always exist regardless of whether the channels 416 * are actually implemented on a PCB or not. 417 */ 418 typedef struct zen_umc_chan { 419 umc_chan_flags_t chan_flags; 420 uint32_t chan_fabid; 421 uint32_t chan_instid; 422 uint32_t chan_logid; 423 uint32_t chan_nrules; 424 uint32_t chan_umccfg_raw; 425 uint32_t chan_datactl_raw; 426 uint32_t chan_eccctl_raw; 427 uint32_t chan_umccap_raw; 428 uint32_t chan_umccap_hi_raw; 429 uint32_t chan_np2_raw; 430 uint32_t chan_np2_space0; 431 /* 432 * These have the clock and speed of the channel in MHz and MT/s 433 * respectively. These are not always a 1:2 ratio. See the definition 434 * and discussion around D_UMC_DRAMCFG. Note, the channel's speed may 435 * not be the maximum supported speed of a DIMM itself. That requires 436 * going into the SPD data on Zen, the UMC doesn't track it because it 437 * doesn't matter to it. There is one of these for each memory P-state. 438 */ 439 uint32_t chan_dramcfg_raw[ZEN_UMC_NMEM_PSTATES]; 440 uint32_t chan_clock[ZEN_UMC_NMEM_PSTATES]; 441 uint32_t chan_speed[ZEN_UMC_NMEM_PSTATES]; 442 umc_dimm_type_t chan_type; 443 df_dram_rule_t chan_rules[ZEN_UMC_MAX_CS_RULES]; 444 chan_offset_t chan_offsets[ZEN_UMC_MAX_DRAM_OFFSET]; 445 umc_dimm_t chan_dimms[ZEN_UMC_MAX_DIMMS]; 446 umc_chan_hash_t chan_hash; 447 } zen_umc_chan_t; 448 449 typedef struct zen_umc_cs_remap { 450 uint_t csr_nremaps; 451 uint16_t csr_remaps[ZEN_UMC_MAX_REMAP_ENTS]; 452 } zen_umc_cs_remap_t; 453 454 typedef enum zen_umc_df_flags { 455 /* 456 * Indicates that the DRAM Hole is valid and in use. 457 */ 458 ZEN_UMC_DF_F_HOLE_VALID = 1 << 0, 459 /* 460 * These next three are used to indicate when hashing is going on, which 461 * bits to use. These are for 64K, 2M, and 1G parts of addresses 462 * respectively. 463 */ 464 ZEN_UMC_DF_F_HASH_16_18 = 1 << 1, 465 ZEN_UMC_DF_F_HASH_21_23 = 1 << 2, 466 ZEN_UMC_DF_F_HASH_30_32 = 1 << 3 467 } zen_umc_df_flags_t; 468 469 typedef struct zen_umc_df { 470 zen_umc_df_flags_t zud_flags; 471 uint_t zud_dfno; 472 uint_t zud_ccm_inst; 473 uint_t zud_dram_nrules; 474 uint_t zud_nchan; 475 uint_t zud_cs_nremap; 476 uint32_t zud_capab; 477 uint32_t zud_hole_raw; 478 uint32_t zud_glob_ctl_raw; 479 uint64_t zud_hole_base; 480 df_dram_rule_t zud_rules[ZEN_UMC_MAX_DRAM_RULES]; 481 zen_umc_cs_remap_t zud_remap[ZEN_UMC_MAX_CS_REMAPS]; 482 zen_umc_chan_t zud_chan[ZEN_UMC_MAX_UMCS]; 483 } zen_umc_df_t; 484 485 typedef enum zen_umc_umc_style { 486 /* 487 * These are UMCs that generally implement the basic DDR4 UMC found in 488 * Zen 1-3 systems. The APU variant does not support multiple banks. 489 */ 490 ZEN_UMC_UMC_S_DDR4, 491 ZEN_UMC_UMC_S_DDR4_APU, 492 /* 493 * This represents a slightly different UMC design that exists in Van 494 * Gogh and Mendocino. In particular, it primarily supports LPDDR5 but 495 * is an extension of the DDR4 UMC in some respects such as the 496 * DramConfiguration register, but otherwise looks more like the DDR5 497 * case. 498 */ 499 ZEN_UMC_UMC_S_HYBRID_LPDDR5, 500 /* 501 * These are UMCs that generally implement the basic DDR5 UMC found in 502 * Zen 4+ (and other) systems. The APU variant does not support multiple 503 * banks. 504 */ 505 ZEN_UMC_UMC_S_DDR5, 506 ZEN_UMC_UMC_S_DDR5_APU 507 } zen_umc_umc_style_t; 508 509 typedef enum zen_umc_fam_flags { 510 /* 511 * Indicates that there's an indirection table for the destinations of 512 * target rules. This is only required to be set explicitly for systems 513 * prior to the DF 4D2 variant as after that remapping support is 514 * indicated in the DF::DfCapability register. 515 */ 516 ZEN_UMC_FAM_F_TARG_REMAP = 1 << 0, 517 /* 518 * Indicates that non-power of two interleave rules are supported and 519 * that we need additional register configuration. 520 */ 521 ZEN_UMC_FAM_F_NP2 = 1 << 1, 522 /* 523 * Indicates that the DF hashing rules to configure COD hashes need to 524 * be checked. 525 */ 526 ZEN_UMC_FAM_F_NORM_HASH = 1 << 2, 527 /* 528 * In DDR4 this indicates presence of the HashRM and in DDR5 the 529 * AddrHash. 530 */ 531 ZEN_UMC_FAM_F_UMC_HASH = 1 << 3, 532 /* 533 * Indicates support for extended UMC registers for larger addresses. 534 * Generally on Server parts. This should only be set if there are 535 * non-reserved bits in the register. 536 */ 537 ZEN_UMC_FAM_F_UMC_EADDR = 1 << 4, 538 /* 539 * Indicates that CS decoder supports an XOR function. 540 */ 541 ZEN_UMC_FAM_F_CS_XOR = 1 << 5 542 } zen_umc_fam_flags_t; 543 544 /* 545 * This structure is meant to contain per SoC family (not CPUID family) 546 * information. This is stuff that we basically need to encode about the 547 * processor itself and relates to its limits, the style it operates in, the 548 * way it works, etc. 549 */ 550 typedef struct zen_umc_fam_data { 551 x86_processor_family_t zufd_family; 552 zen_umc_fam_flags_t zufd_flags; 553 uint8_t zufd_dram_nrules; 554 uint8_t zufd_cs_nrules; 555 zen_umc_umc_style_t zufd_umc_style; 556 umc_chan_hash_flags_t zufd_chan_hash; 557 } zen_umc_fam_data_t; 558 559 /* 560 * The top-level data structure for the system. This is a single structure that 561 * represents everything that could possibly exist and is filled in with what we 562 * actually discover. 563 */ 564 typedef struct zen_umc { 565 uint64_t umc_tom; 566 uint64_t umc_tom2; 567 dev_info_t *umc_dip; 568 x86_processor_family_t umc_family; 569 df_rev_t umc_df_rev; 570 const zen_umc_fam_data_t *umc_fdata; 571 df_fabric_decomp_t umc_decomp; 572 uint_t umc_ndfs; 573 zen_umc_df_t umc_dfs[ZEN_UMC_MAX_DFS]; 574 /* 575 * This lock protects the data underneath here. 576 */ 577 kmutex_t umc_nvl_lock; 578 nvlist_t *umc_decoder_nvl; 579 char *umc_decoder_buf; 580 size_t umc_decoder_len; 581 } zen_umc_t; 582 583 typedef enum zen_umc_decode_failure { 584 ZEN_UMC_DECODE_F_NONE = 0, 585 /* 586 * Indicates that the address was not contained within the TOM and TOM2 587 * regions that indicate DRAM (or was in a reserved hole). 588 */ 589 ZEN_UMC_DECODE_F_OUTSIDE_DRAM, 590 /* 591 * Indicates that we could not find a DF rule in the CCM rule that 592 * claims to honor this address. 593 */ 594 ZEN_UMC_DECODE_F_NO_DF_RULE, 595 /* 596 * Indicates that trying to construct the interleave address to use 597 * would have led to an underflow somehow. 598 */ 599 ZEN_UMC_DECODE_F_ILEAVE_UNDERFLOW, 600 /* 601 * Indicates that we do not currently support decoding the indicated 602 * channel interleave type. 603 */ 604 ZEN_UMC_DECODE_F_CHAN_ILEAVE_NOTSUP, 605 /* 606 * Indicates that we found a COD hash rule that had a non-zero socket or 607 * die interleave, which isn't supported and we don't know how to 608 * decode. 609 */ 610 ZEN_UMC_DECODE_F_COD_BAD_ILEAVE, 611 /* 612 * This is similar to the above, but indicates that we hit a bad NPS 613 * interleave rule instead of a COD. 614 */ 615 ZEN_UMC_DECODE_F_NPS_BAD_ILEAVE, 616 /* 617 * Indicates that somehow we thought we should use a remap rule set that 618 * was beyond our capabilities. 619 */ 620 ZEN_UMC_DECODE_F_BAD_REMAP_SET, 621 /* 622 * Indicates that we tried to find an index for the remap rules; 623 * however, the logical component ID was outside the range of the number 624 * of entries that we have. 625 */ 626 ZEN_UMC_DECODE_F_BAD_REMAP_ENTRY, 627 /* 628 * Indicates that the remap rule had an invalid component bit set in its 629 * mask. 630 */ 631 ZEN_UMC_DECODE_F_REMAP_HAS_BAD_COMP, 632 /* 633 * Indicates that we could not find a UMC with the fabric ID we thought 634 * we should have. 635 */ 636 ZEN_UMC_DECODE_F_CANNOT_MAP_FABID, 637 /* 638 * Indicates that somehow the UMC we found did not actually contain a 639 * DRAM rule that covered our original PA. 640 */ 641 ZEN_UMC_DECODE_F_UMC_DOESNT_HAVE_PA, 642 /* 643 * Indicates that we would have somehow underflowed the address 644 * calculations normalizing the system address. 645 */ 646 ZEN_UMC_DECODE_F_CALC_NORM_UNDERFLOW, 647 /* 648 * Indicates that none of the UMC's chip-selects actually matched a base 649 * or secondary. 650 */ 651 ZEN_UMC_DECODE_F_NO_CS_BASE_MATCH, 652 } zen_umc_decode_failure_t; 653 654 /* 655 * This struct accumulates all of our decoding logic and states and we use it so 656 * it's easier for us to look at what's going on and the decisions that we made 657 * along the way. 658 */ 659 typedef struct zen_umc_decoder { 660 zen_umc_decode_failure_t dec_fail; 661 uint64_t dec_fail_data; 662 uint64_t dec_pa; 663 const zen_umc_df_t *dec_df_rulesrc; 664 uint32_t dec_df_ruleno; 665 const df_dram_rule_t *dec_df_rule; 666 uint64_t dec_ilv_pa; 667 /* 668 * These three values represent the IDs that we extract from the 669 * interleave address. 670 */ 671 uint32_t dec_ilv_sock; 672 uint32_t dec_ilv_die; 673 uint32_t dec_ilv_chan; 674 uint32_t dec_ilv_fabid; 675 uint32_t dec_log_fabid; 676 uint32_t dec_remap_comp; 677 uint32_t dec_targ_fabid; 678 const zen_umc_chan_t *dec_umc_chan; 679 uint32_t dec_umc_ruleno; 680 uint64_t dec_norm_addr; 681 const umc_dimm_t *dec_dimm; 682 const umc_cs_t *dec_cs; 683 boolean_t dec_cs_sec; 684 uint32_t dec_dimm_col; 685 uint32_t dec_dimm_row; 686 uint8_t dec_log_csno; 687 uint8_t dec_dimm_bank; 688 uint8_t dec_dimm_bank_group; 689 uint8_t dec_dimm_subchan; 690 uint8_t dec_dimm_rm; 691 uint8_t dec_chan_csno; 692 uint8_t dec_dimm_no; 693 uint8_t dec_dimm_csno; 694 } zen_umc_decoder_t; 695 696 /* 697 * Decoding and normalization routines. 698 */ 699 extern boolean_t zen_umc_decode_pa(const zen_umc_t *, const uint64_t, 700 zen_umc_decoder_t *); 701 702 /* 703 * Encoding and decoding 704 */ 705 extern nvlist_t *zen_umc_dump_decoder(zen_umc_t *); 706 extern boolean_t zen_umc_restore_decoder(nvlist_t *, zen_umc_t *); 707 708 #ifdef __cplusplus 709 } 710 #endif 711 712 #endif /* _ZEN_UMC_H */ 713