Re: [PATCH 2/2] x86/memtype: Deduplicate rendering of X86_MT_*

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> 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