From: Chuck Zmudzinski <brchuckz@netscape.net>
To: Thorsten Leemhuis <regressions@leemhuis.info>,
Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc: jbeulich@suse.com, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>, Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
regressions@lists.linux.dev
Subject: Re: [PATCH 0/3] x86: make pat and mtrr independent from each other
Date: Sat, 13 Aug 2022 12:56:12 -0400 [thread overview]
Message-ID: <a0ce2f59-b653-fa8b-a016-1335f05c86ae@netscape.net> (raw)
In-Reply-To: <efbde93b-e280-0e40-798d-dc7bf8ca83cf@leemhuis.info>
On 7/17/22 3:55 AM, Thorsten Leemhuis wrote:
> Hi Juergen!
>
> On 15.07.22 16:25, Juergen Gross wrote:
> > Today PAT can't be used without MTRR being available, unless MTRR is at
> > least configured via CONFIG_MTRR and the system is running as Xen PV
> > guest. In this case PAT is automatically available via the hypervisor,
> > but the PAT MSR can't be modified by the kernel and MTRR is disabled.
> >
> > As an additional complexity the availability of PAT can't be queried
> > via pat_enabled() in the Xen PV case, as the lack of MTRR will set PAT
> > to be disabled. This leads to some drivers believing that not all cache
> > modes are available, resulting in failures or degraded functionality.
> >
> > The same applies to a kernel built with no MTRR support: it won't
> > allow to use the PAT MSR, even if there is no technical reason for
> > that, other than setting up PAT on all cpus the same way (which is a
> > requirement of the processor's cache management) is relying on some
> > MTRR specific code.
> >
> > Fix all of that by:
> >
> > - moving the function needed by PAT from MTRR specific code one level
> > up
> > - adding a PAT indirection layer supporting the 3 cases "no or disabled
> > PAT", "PAT under kernel control", and "PAT under Xen control"
> > - removing the dependency of PAT on MTRR
>
> Thx for working on this. If you need to respin these patches for one
> reason or another, could you do me a favor and add proper 'Link:' tags
> pointing to all reports about this issue? e.g. like this:
>
> Link: https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
>
> These tags are considered important by Linus[1] and others, as they
> allow anyone to look into the backstory weeks or years from now. That is
> why they should be placed in cases like this, as
> Documentation/process/submitting-patches.rst and
> Documentation/process/5.Posting.rst explain in more detail. I care
> personally, because these tags make my regression tracking efforts a
> whole lot easier, as they allow my tracking bot 'regzbot' to
> automatically connect reports with patches posted or committed to fix
> tracked regressions.
>
> [1] see for example:
> https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
> https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
>
> BTW, let me tell regzbot to monitor this thread:
>
> #regzbot ^backmonitor:
> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
Hi Thorsten,
This appears stalled again and we are now over three months
from the first report of the regression, The only excuse for
ignoring your comments, and other comments on the patches
in this patch series for this long a time is that the patch series
for some reason cannot be considered a true regression. If this is a
regression, then, IMHO, this needs to have a higher priority by the
maintainers, or the maintainers need to explain why this regression
cannot be fixed in a more timely manner. But continued silence
by the maintainers is unacceptable, IMHO. This is especially true
in this case when multiple fixes for the regression have been
identified and the maintainers have not yet clearly explained why
at least a fix, even if temporary, cannot be applied immediately
while we wait for a more comprehensive fix.
At the very least, I would expect Juergen to reply here and say that
he is delayed but does plan to spin up an updated version and include
the necessary links in the new version to facilitate your tracking of
the regression. Why the silence from Juergen here?
Best regards,
Chuck
next prev parent reply other threads:[~2022-08-13 16:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 14:25 Juergen Gross
2022-07-15 14:25 ` [PATCH 1/3] x86: move some code out of arch/x86/kernel/cpu/mtrr Juergen Gross
2022-07-18 12:20 ` Borislav Petkov
2022-07-15 14:25 ` [PATCH 2/3] x86: add wrapper functions for mtrr functions handling also pat Juergen Gross
2022-07-15 16:41 ` Rafael J. Wysocki
2022-07-19 10:47 ` Borislav Petkov
2022-07-15 14:25 ` [PATCH 3/3] x86: decouple pat and mtrr handling Juergen Gross
2022-07-19 15:15 ` Borislav Petkov
2022-08-13 16:56 ` PING " Chuck Zmudzinski
2022-08-13 17:20 ` Borislav Petkov
2022-08-13 21:40 ` Chuck Zmudzinski
2022-08-13 21:48 ` Borislav Petkov
2022-08-13 22:41 ` Chuck Zmudzinski
2022-08-16 18:31 ` Chuck Zmudzinski
2022-08-17 9:17 ` Juergen Gross
2022-07-20 1:12 ` Chuck Zmudzinski
2022-07-16 11:32 ` [PATCH 0/3] x86: make pat and mtrr independent from each other Chuck Zmudzinski
2022-07-16 11:42 ` Borislav Petkov
2022-07-17 4:06 ` Chuck Zmudzinski
2022-07-16 12:01 ` Chuck Zmudzinski
2022-07-17 7:55 ` Thorsten Leemhuis
2022-07-18 11:32 ` Chuck Zmudzinski
2022-07-19 13:16 ` Chuck Zmudzinski
2022-08-13 16:56 ` Chuck Zmudzinski [this message]
2022-08-14 7:42 ` Chuck Zmudzinski
2022-08-14 8:08 ` Juergen Gross
2022-08-15 3:23 ` Chuck Zmudzinski
2022-08-15 16:56 ` Chuck Zmudzinski
2022-08-15 18:00 ` Thorsten Leemhuis
2022-08-15 18:17 ` Chuck Zmudzinski
2022-08-16 14:41 ` Thorsten Leemhuis
2022-08-16 16:16 ` Chuck Zmudzinski
2022-08-16 16:53 ` Thorsten Leemhuis
2022-08-16 17:28 ` Chuck Zmudzinski
2022-08-18 18:54 ` Chuck Zmudzinski
2022-08-14 9:19 ` Chuck Zmudzinski
2022-08-14 9:50 ` Greg KH
2022-08-14 12:08 ` Chuck Zmudzinski
2022-08-14 13:01 ` Greg KH
2022-08-14 16:03 ` Chuck Zmudzinski
2022-08-14 19:52 ` Chuck Zmudzinski
2022-08-15 16:04 ` 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=a0ce2f59-b653-fa8b-a016-1335f05c86ae@netscape.net \
--to=brchuckz@netscape.net \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®