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
