Re: [PATCH 5.19 109/158] x86/PAT: Have pat_enabled() properly reflect state when running on Xen

[Chuck Zmudzinski]

On 8/29/2022 6:59 AM, Greg Kroah-Hartman wrote:
> From: Jan Beulich <jbeulich@xxxxxxxx>
>
> commit 72cbc8f04fe2fa93443c0fcccb7ad91dfea3d9ce upstream.
>
> After commit ID in the Fixes: tag, pat_enabled() returns false (because
> of PAT initialization being suppressed in the absence of MTRRs being
> announced to be available).
>
> This has become a problem: the i915 driver now fails to initialize when
> running PV on Xen (i915_gem_object_pin_map() is where I located the
> induced failure), and its error handling is flaky enough to (at least
> sometimes) result in a hung system.
>
> Yet even beyond that problem the keying of the use of WC mappings to
> pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
> graphics frame buffer accesses would have been quite a bit less optimal
> than possible.
>
> Arrange for the function to return true in such environments, without
> undermining the rest of PAT MSR management logic considering PAT to be
> disabled: specifically, no writes to the PAT MSR should occur.
>
> For the new boolean to live in .init.data, init_cache_modes() also needs
> moving to .init.text (where it could/should have lived already before).
>
>   [ bp: This is the "small fix" variant for stable. It'll get replaced
>     with a proper PAT and MTRR detection split upstream but that is too
>     involved for a stable backport.
>     - additional touchups to commit msg. Use cpu_feature_enabled(). ]
>
> Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Signed-off-by: Borislav Petkov <bp@xxxxxxx>
> Acked-by: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx>
> Cc: Juergen Gross <jgross@xxxxxxxx>
> Cc: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
> Link: https://lore.kernel.org/r/9385fa60-fa5d-f559-a137-6608408f88b0@xxxxxxxx
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> ---
>  arch/x86/mm/pat/memtype.c |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> --- 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;
>  
> @@ -86,6 +87,7 @@ void pat_disable(const char *msg_reason)
>  static int __init nopat(char *str)
>  {
>  	pat_disable("PAT support disabled via boot option.");
> +	pat_force_disabled = true;
>  	return 0;
>  }
>  early_param("nopat", nopat);
> @@ -272,7 +274,7 @@ static void pat_ap_init(u64 pat)
>  	wrmsrl(MSR_IA32_CR_PAT, pat);
>  }
>  
> -void init_cache_modes(void)
> +void __init init_cache_modes(void)
>  {
>  	u64 pat = 0;
>  
> @@ -313,6 +315,12 @@ void init_cache_modes(void)
>  		 */
>  		pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
>  		      PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
> +	} else if (!pat_force_disabled && cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) {
> +		/*
> +		 * Clearly PAT is enabled underneath. Allow pat_enabled() to
> +		 * reflect this.
> +		 */
> +		pat_bp_enabled = true;
>  	}
>  
>  	__init_cache_modes(pat);
>
>

Dear Boris, Jan, Juergen, Thorsten, and Greg,

Just a note to say thanks to everyone who worked on this regression.
I just upgraded my Xen PV dom0 on fc36 that was affected with the
Fedora build of 5.19.6, which has the fix, and it works fine.

Thanks again,

Chuck