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,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Subject: x86/PAT: Report PAT on CPUs that support PAT without MTRR
Date: Wed, 13 Jul 2022 11:09:10 +0200 [thread overview]
Message-ID: <e15c0030-3270-f524-17e4-c482e971eb88@suse.com> (raw)
In-Reply-To: <3d3f0766-2e06-428b-65bb-5d9f778a2baf@netscape.net>
On 13.07.2022 10:51, Chuck Zmudzinski wrote:
> On 7/13/22 2:18 AM, Jan Beulich wrote:
>> On 13.07.2022 03:36, Chuck Zmudzinski wrote:
>>> v2: *Add force_pat_disabled variable to fix "nopat" on Xen PV (Jan Beulich)
>>> *Add the necessary code to incorporate the "nopat" fix
>>> *void init_cache_modes(void) -> void __init init_cache_modes(void)
>>> *Add Jan Beulich as Co-developer (Jan has not signed off yet)
>>> *Expand the commit message to include relevant parts of the commit
>>> message of Jan Beulich's proposed patch for this problem
>>> *Fix 'else if ... {' placement and indentation
>>> *Remove indication the backport to stable branches is only back to 5.17.y
>>>
>>> I think these changes address all the comments on the original patch
>>>
>>> I added Jan Beulich as a Co-developer because Juergen Gross asked me to
>>> include Jan's idea for fixing "nopat" that was missing from the first
>>> version of the patch.
>>
>> You've sufficiently altered this change to clearly no longer want my
>> S-o-b; unfortunately in fact I think you broke things:
>
> Well, I hope we can come to an agreement so I have
> your S-o-b. But that would probably require me to remove
> Juergen's R-b.
>
>>> @@ -292,7 +294,7 @@ void init_cache_modes(void)
>>> rdmsrl(MSR_IA32_CR_PAT, pat);
>>> }
>>>
>>> - if (!pat) {
>>> + if (!pat || pat_force_disabled) {
>>
>> By checking the new variable here ...
>>
>>> /*
>>> * No PAT. Emulate the PAT table that corresponds to the two
>>> * cache bits, PWT (Write Through) and PCD (Cache Disable).
>>> @@ -313,6 +315,16 @@ 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);
>>
>> ... you put in place a software view which doesn't match hardware. I
>> continue to think that ...
>>
>>> + } else if (!pat_bp_enabled) {
>>
>> ... the variable wants checking here instead (at which point, yes,
>> this comes quite close to simply being a v2 of my original patch).
>>
>> By using !pat_bp_enabled here you actually broaden where the change
>> would take effect. Iirc Boris had asked to narrow things (besides
>> voicing opposition to this approach altogether). Even without that
>> request I wonder whether you aren't going to far with this.
>>
>> Jan
>
> I thought about checking for the administrator's "nopat"
> setting where you suggest which would limit the effect
> of "nopat" to not reporting PAT as enabled to device
> drivers who query for PAT availability using pat_enabled().
> The main reason I did not do that is that due to the fact
> that we cannot write to the PAT MSR, we cannot really
> disable PAT. But we come closer to respecting the wishes
> of the administrator by configuring the caching modes as
> if PAT is actually disabled by the hardware or firmware
> when in fact it is not.
>
> What would you propose logging as a message when
> we report PAT as disabled via pat_enabled()? The main
> reason I did not choose to check the new variable in the
> new 'else if' block is that I could not figure out what to
> tell the administrator in that case. I think we would have
> to log something like, "nopat is set, but we cannot disable
> PAT, doing our best to disable PAT by not reporting PAT
> as enabled via pat_enabled(), but that does not guarantee
> that kernel drivers and components cannot use PAT if they
> query for PAT support using boot_cpu_has(X86_FEATURE_PAT)
> instead of pat_enabled()." However, I acknowledge WC mappings
> would still be disabled because arch_can_pci_mmap_wc() will
> be false if pat_enabled() is false.
>
> Perhaps we also need to log something if we keep the
> check for "nopat" where I placed it. We could say something
> like: "nopat is set, but we cannot disable hardware/firmware
> PAT support, so we are emulating as if there is no PAT support
> which puts in place a software view that does not match
> hardware."
>
> No matter what, because we cannot write to PAT MSR in
> the Xen PV case, we probably need to log something to
> explain the problems associated with trying to honor the
> administrator's request. Also, what log level should it be.
> Should it be a pr_warn instead of a pr_info?
I'm afraid I'm the wrong one to answer logging questions. As you
can see from my original patch, I didn't add any new logging (and
no addition was requested in the comments that I have got). I also
don't think "nopat" has ever meant "disable PAT", as the feature
is either there or not. Instead I think it was always seen as
"disable fiddling with PAT", which by implication means using
whatever is there (if the feature / MSR itself is available).
Jan
next prev parent reply other threads:[~2022-07-13 9:09 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 [this message]
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
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=e15c0030-3270-f524-17e4-c482e971eb88@suse.com \
--to=jbeulich@suse.com \
--cc=Tianyu.Lan@microsoft.com \
--cc=bp@alien8.de \
--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=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).