From: Jan Beulich <jbeulich@suse.com>
To: Chuck Zmudzinski <brchuckz@netscape.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Dan Williams <dan.j.williams@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Jane Chu <jane.chu@oracle.com>,
Tianyu Lan <Tianyu.Lan@microsoft.com>,
Randy Dunlap <rdunlap@infradead.org>,
Sean Christopherson <seanjc@google.com>,
Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org, stable@vger.kernel.org,
Thorsten Leemhuis <regressions@leemhuis.info>,
Chuck Zmudzinski <brchuckz@aol.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Subject: x86/PAT: Report PAT on CPUs that support PAT without MTRR
Date: Fri, 15 Jul 2022 12:05:39 +0200 [thread overview]
Message-ID: <d3555a74-d0cb-ca73-eb2e-082f882b5c81@suse.com> (raw)
In-Reply-To: <56a6ab5f-06fb-fa11-5966-cb23cb276fa6@netscape.net>
On 15.07.2022 04:07, Chuck Zmudzinski wrote:
> On 7/14/2022 1:30 AM, Thorsten Leemhuis wrote:
>> On 13.07.22 03:36, Chuck Zmudzinski wrote:
>>> The commit 99c13b8c8896d7bcb92753bf
>>> ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
>>> incorrectly failed to account for the case in init_cache_modes() when
>>> CPUs do support PAT and falsely reported PAT to be disabled when in
>>> fact PAT is enabled. In some environments, notably in Xen PV domains,
>>> MTRR is disabled but PAT is still enabled, and that is the case
>>> that the aforementioned commit failed to account for.
>>>
>>> As an unfortunate consequnce, the pat_enabled() function currently does
>>> not correctly report that PAT is enabled in such environments. The fix
>>> is implemented in init_cache_modes() by setting pat_bp_enabled to true
>>> in init_cache_modes() for the case that commit 99c13b8c8896d7bcb92753bf
>>> ("x86/mm/pat: Don't report PAT on CPUs that don't support it") failed
>>> to account for.
>>>
>>> This approach arranges for pat_enabled() to return true in the Xen PV
>>> environment without undermining the rest of PAT MSR management logic
>>> that considers PAT to be disabled: Specifically, no writes to the PAT
>>> MSR should occur.
>>>
>>> This patch fixes a regression that some users are experiencing with
>>> Linux as a Xen Dom0 driving particular Intel graphics devices by
>>> correctly reporting to the Intel i915 driver that PAT is enabled where
>>> previously it was falsely reporting that PAT is disabled. Some users
>>> are experiencing system hangs in Xen PV Dom0 and all users on Xen PV
>>> Dom0 are experiencing reduced graphics performance because 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 are quite a bit
>>> less performant than possible without this patch.
>>>
>>> Also, with the current code, in the Xen PV environment, PAT will not be
>>> disabled if the administrator sets the "nopat" boot option. Introduce
>>> a new boolean variable, pat_force_disable, to forcibly disable PAT
>>> when the administrator sets the "nopat" option to override the default
>>> behavior of using the PAT configuration that Xen has provided.
>>>
>>> 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).
>>>
>>> Fixes: 99c13b8c8896d7bcb92753bf ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
>>
>> BTW, "submitting-patches.rst" says it should just be "the first 12
>> characters of the SHA-1 ID"
>
> Actually it says "at least", so more that 12 is It is probably safest
> to put the entire SHA-1 ID in because of the possibility of
> a collision. At least that's how I understand what
> submitting-patches.rst.
>
>>
>>> Co-developed-by: Jan Beulich <jbeulich@suse.com>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
>>
>> Sorry, have to ask: is this supposed to finally fix this regression?
>> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
>
> Yes that's the first report I saw to lkml about this isssue. So if I submit
> a v3 I will include that. But my patch does not have a sign-off from the
> Co-developer as I mentioned in a message earlier today, and the
> discussion that has ensued leads me to think a better solution is to just
> revert the commit in the i915 driver instead, and leave the bigger questions
> for Juergen Gross and his plans to re-work the x86/PAT code in September,
> as he said on this thread in the last couple of days. This patch is dead
> now,
> as far as I can tell, because the Co-developer is not cooperating.
???
Jan
next prev parent reply other threads:[~2022-07-15 10:07 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9d5070ae4f3e956a95d3f50e24f1a93488b9ff52.1657671676.git.brchuckz.ref@aol.com>
2022-07-13 1:36 ` [PATCH v2] Subject: x86/PAT: Report PAT on CPUs that support PAT without MTRR Chuck Zmudzinski
2022-07-13 4:12 ` Juergen Gross
2022-07-13 6:18 ` Jan Beulich
2022-07-13 8:51 ` Chuck Zmudzinski
2022-07-13 9:09 ` Jan Beulich
2022-07-13 10:36 ` Chuck Zmudzinski
2022-07-13 11:10 ` Chuck Zmudzinski
2022-07-13 13:34 ` Jan Beulich
2022-07-13 13:45 ` Juergen Gross
2022-07-13 17:01 ` Chuck Zmudzinski
2022-07-13 19:07 ` Chuck Zmudzinski
2022-07-13 19:22 ` Chuck Zmudzinski
2022-07-13 19:38 ` Chuck Zmudzinski
2022-07-13 22:12 ` Chuck Zmudzinski
2022-07-13 13:49 ` Chuck Zmudzinski
2022-07-13 13:52 ` Jan Beulich
2022-07-13 15:02 ` Chuck Zmudzinski
2022-07-13 15:05 ` Jan Beulich
2022-07-14 5:30 ` Thorsten Leemhuis
2022-07-15 2:07 ` Chuck Zmudzinski
2022-07-15 5:00 ` Thorsten Leemhuis
2022-07-15 10:05 ` Jan Beulich [this message]
2022-07-15 19:53 ` Chuck Zmudzinski
2022-07-16 11:02 ` Chuck Zmudzinski
2022-07-18 6:07 ` Jan Beulich
2022-07-18 11:31 ` Chuck Zmudzinski
2022-07-18 11:39 ` Jan Beulich
2022-07-18 11:45 ` Chuck Zmudzinski
2022-07-18 12:12 ` Chuck Zmudzinski
2022-08-17 16:39 ` Chuck Zmudzinski
2022-07-14 5:40 ` Juergen Gross
2022-07-14 6:28 ` Jan Beulich
2022-07-15 2:19 ` Chuck Zmudzinski
2022-07-15 2:53 ` Chuck Zmudzinski
2022-07-15 2:58 ` Chuck Zmudzinski
2022-07-15 4:22 ` Juergen Gross
2022-07-15 4:42 ` Chuck Zmudzinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3555a74-d0cb-ca73-eb2e-082f882b5c81@suse.com \
--to=jbeulich@suse.com \
--cc=Tianyu.Lan@microsoft.com \
--cc=bp@alien8.de \
--cc=brchuckz@aol.com \
--cc=brchuckz@netscape.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jane.chu@oracle.com \
--cc=jgross@suse.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=regressions@leemhuis.info \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).