On 05.07.2022 17:04, Borislav Petkov wrote:
> On Thu, Apr 28, 2022 at 04:50:29PM +0200, Jan Beulich wrote:
>> --- a/arch/x86/mm/pat/memtype.c
>> +++ b/arch/x86/mm/pat/memtype.c
>> @@ -62,6 +62,7 @@
>>
>> static bool __read_mostly pat_bp_initialized;
>> static bool __read_mostly pat_disabled = !IS_ENABLED(CONFIG_X86_PAT);
>> +static bool __initdata pat_force_disabled = !IS_ENABLED(CONFIG_X86_PAT);
>> static bool __read_mostly pat_bp_enabled;
>> static bool __read_mostly pat_cm_initialized;
>
> Why yet another boolean var?
Re-using pat_disabled like you do in your suggestion below won't
work, because mtrr_bp_init() calls pat_disable() when MTRRs
appear to be disabled (from the kernel's view). The goal is to
honor "nopat" without honoring any other calls to pat_disable().
> Why not extend pat_enabled() to reflect the Xen case and explain it
> properly above it?
I can probably fiddle with pat_enabled() instead of with
init_cache_modes(), but when making the change I had the feeling
this might be less liked (as looking more hacky, at least to me).
But besides the "where" the other question is: Do you really want
me to limit this to Xen/PV, rather than - as I have it now -
extending it to any hypervisor, which may behave in similar ways?
Jan
> My comment is likely wrong because I don't know what the Xen HV hides or
> doesn't but you get the idea...
>
> diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> index d5ef64ddd35e..a8f1a02f9bc2 100644
> --- a/arch/x86/mm/pat/memtype.c
> +++ b/arch/x86/mm/pat/memtype.c
> @@ -92,6 +92,13 @@ early_param("nopat", nopat);
>
> bool pat_enabled(void)
> {
> + /*
> + * Xen PV doesn't expose the PAT MSR to dom0 so the proper init path
> + * there cannot be exercised. Announce PAT is enabled in that case too.
> + */
> + if (cpu_feature_enabled(X86_FEATURE_XENPV) && !pat_disabled)
> + return true;
> +
> return pat_bp_enabled;
> }
> EXPORT_SYMBOL_GPL(pat_enabled);
>
