From: Chuck Zmudzinski <brchuckz@netscape.net>
To: Jan Beulich <jbeulich@suse.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Borislav Petkov <bp@alien8.de>
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>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Subject: x86/PAT: Report PAT on CPUs that support PAT without MTRR
Date: Mon, 18 Jul 2022 08:12:42 -0400 [thread overview]
Message-ID: <e2113207-623e-77cd-9e1c-fffe951bcd8d@netscape.net> (raw)
In-Reply-To: <80b413d1-287a-61a3-656d-9ea680f00a90@suse.com>
On 7/18/2022 7:39 AM, Jan Beulich wrote:
> On 18.07.2022 13:31, Chuck Zmudzinski wrote:
> > On 7/18/2022 2:07 AM, Jan Beulich wrote:
> >> On 15.07.2022 21:53, Chuck Zmudzinski wrote:
> >>> Two things I see here in my efforts to get a patch to fix this regression:
> >>>
> >>> 1. Does Xen have plans to give Linux running in Dom0 write-access to the
> >>> PAT MSR?
> >>
> >> No, as this is not technically feasible (all physical CPUs should run
> >> with the same value in the MSR, or else other issues arise).
> >>
> >>> 2. Does Xen have plans to expose MTRRs to Linux running in Dom0?
> >>
> >> Yen does expose MTRRs to PV Dom0, but via a hypercall mechanism. I
> >> don't think there are plans on the Xen side to support the MSR
> >> interface (and hence to expose the CPUID bit), and iirc there are
> >> no plans on the Linux side to use the MTRR interface. This also
> >> wouldn't really make sense anymore now that it has become quite
> >> clear that Linux wants to have PAT working without depending on
> >> MTRR.
> >
> > I am not so sure about that, given what Borislav Petkov
> > said when commenting on your patch here:
> >
> > https://lore.kernel.org/lkml/YsRjX%2FU1XN8rq+8u@zn.tnic/
> >
> > Specifically, Borislav Petkov wrote on Tue, 5 Jul 2022 18:14:23 +0200:
> >
> > Actually, the current goal is to adjust Xen dom0 because:
> >
> > 1. it uses the PAT code
> >
> > 2. but then it does something special and hides the MTRRs
> >
> > which is not something real hardware does.
> >
> > So this one-off thing should be prominent, visible and not get in the
> > way.
> >
> > --------------end of Borislav Petkov quote-----------
>
> And then, a day later, he said
>
> "So I'm being told that it would be generally beneficial for all kinds of
> virtualization solutions to be able to support PAT only, without MTRRs
> so it would be interesting to see how ugly it would become to decouple
> PAT from MTRRs in Linux..."
What if it proves to be too ugly to decouple PAT from MTRRs? Then
I doubt that "Linux wants to have PAT working without depending
on MTRR." We can hope that Juergen's work to decouple PAT from
MTRRs is not so ugly that it cannot be done, but that is by no means
certain at this point. At the very least, this means the fix to the
regression
will be at least delayed considerably, and possibly this means this
regression will never be fixed in the mainline kernel release.
Chuck
next prev parent reply other threads:[~2022-07-18 12:13 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
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 [this message]
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=e2113207-623e-77cd-9e1c-fffe951bcd8d@netscape.net \
--to=brchuckz@netscape.net \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.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=regressions@leemhuis.info \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.