On 06.02.2026 14:13, Andrew Cooper wrote: > The MTRR infrastructure has two different copies of mtrr_attrib_to_str(), one > in .init and one in regular .text. EPT has another variation. > > All 3 are incomplete; they encode only the non-reserved values for the task, > but hiding reserved values with ?'s is detrimental to the diagnostic purpose > of these existing in the first place. > > Implement a single function which covers all the architectural values. > > Signed-off-by: Andrew Cooper <[email protected]> > --- > CC: Jan Beulich <[email protected]> > CC: Roger Pau Monné <[email protected]> > > Yes I know EPT tries to render the reserved reserved encodings numerically. > It's a cute trick, but does get foiled by the '[MTRR_NUM_TYPES] = "??";' row > which breaks things.
Does it? 7 isn't UC- there, but is instead reserved, which we leverage to get EPT-misconfig exits. 7 also isn't UC- when used in MTRRs; that's a PAT-only type. I think we better wouldn't mix those. Therefore I'm also not really happy with x86_mt_name() as a name - it should be clear from the name whether this is about MTRR (and EPT memory type) or PAT. > Putting this in traps.c isn't great, but there isn't an obviously better place > either. Any reason not to put them in one of the two mtrr/*.c files? Are we entertaining the idea of allowing to compile out mtrr/? > @@ -214,7 +201,7 @@ static void __init print_mtrr_state(const char *level) > level, i, > width, mtrr_state.var_ranges[i].base >> 12, > width, mtrr_state.var_ranges[i].mask >> 12, > - mtrr_attrib_to_str(mtrr_state.var_ranges[i].base > & > + x86_mt_name(mtrr_state.var_ranges[i].base & > MTRR_PHYSBASE_TYPE_MASK)); Nit: Indentation of this line then wants changing, too. Jan
