[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05b5e672-0a1b-2d00-a879-b5127a94973f@suse.com>
Date: Mon, 4 Jul 2022 14:26:58 +0200
From: Jan Beulich <jbeulich@...e.com>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: lkml <linux-kernel@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
Andrew Lutomirski <luto@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: Ping: [PATCH] x86/PAT: have pat_enabled() properly reflect state
when running on e.g. Xen
On 04.07.2022 13:58, Thorsten Leemhuis wrote:
> On 25.05.22 10:55, Jan Beulich wrote:
>> On 28.04.2022 16:50, Jan Beulich wrote:
>>> The latest with commit bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT
>>> with pat_enabled()") pat_enabled() returning false (because of PAT
>>> initialization being suppressed in the absence of MTRRs being announced
>>> to be available) 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
>>> performant 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).
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@...e.com>
>>
>> The Linux kernel regression tracker is pestering me because things are
>> taking so long (effectively quoting him), and alternative proposals
>> made so far look to have more severe downsides.
>
> Has any progress been made with this patch? It afaics is meant to fix
> this regression, which ideally should have been fixed weeks ago (btw:
> adding a "Link:" tag pointing to it would be good):
> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
>
> According to Juergen it's still needed:
> https://lore.kernel.org/lkml/c5515533-29a9-9e91-5a36-45f00f25b37b@suse.com/
>
> Or was a different solution found to fix that regression?
No progress and no alternatives I'm aware of.
Jan
Powered by blists - more mailing lists