From: Toshi Kani <toshi.kani@hpe.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mcgrof@suse.com" <mcgrof@suse.com>,
"jgross@suse.com" <jgross@suse.com>,
"paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table
Date: Fri, 11 Mar 2016 12:28:24 -0700 [thread overview]
Message-ID: <1457724504.6393.151.camel@hpe.com> (raw)
In-Reply-To: <20160311155439.GF4312@pd.tnic>
On Fri, 2016-03-11 at 16:54 +0100, Borislav Petkov wrote:
> On Fri, Mar 11, 2016 at 09:27:40AM -0700, Toshi Kani wrote:
> > How about pat_disable_setup()? It's only used for the disabled case,
> > so I'd prefer to keep the word "disable".
>
> What for?
>
> Renaming pat_init() to pat_setup() is perfectly fine as it sets up PAT
> after looking at pat_disabled() setting and after looking at the CPU
> vendor. Sounds like a perfectly sane design to me.
Sorry, I meant to say -- "How about renaming pat_disable_init() to
pat_disable_setup()?" since I thought you had suggested to rename
pat_disable_init() to pat_setup(). I am still in favor of having a
separate setup func for the disabled case.
> > Yes, calling pat_init() from pat_disable() works too. I changed it in
> > this way because:
> > - pat_bsp_init() calls pat_disabled() in an error case. It is simpler
> > to avoid a recursive call to pat_init().
>
> So do this:
>
> static inline void pat_disable(const char *reason)
> {
> if (!__pat_enabled)
> return;
Hmm... I do not think I understand this. When pat_bsp_init() calls
pat_disable(), 'pat' has been set to the "Full PAT support" setup. So, we
need to reset 'pat' to the "No PAT" setup. How is this handled in your
case?
> > - pat_bsp_init() has two different error paths, 1) call pat_disable()
> > and return, and 2) goto done and call pat_init_cache_modes(). We can
> > remove case 2) to keep the error handling consistent in this way.
>
> Above.
>
> > > Then you don't have to add yet another static disable_init_done but
> > > rely on boot_cpu_done which gets set in pat_init().
> >
> > Right, but it will do 'boot_cpu_done = true' twice, and this implicit
> > recursive call may cause an issue in future if someone makes change
> > carelessly.
>
> So move boot_cpu_done into pat_bsp_init() and make it protect that
> function from a being called a second time.
I think this leads more complication in the end. pat_init() covers (too)
many scenarios already, and moving the disabled setup case out will
simplify it, IMHO.
Thanks,
-Toshi
next prev parent reply other threads:[~2016-03-11 18:35 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 4:45 [PATCH 0/2] Refactor MTRR and PAT initializations Toshi Kani
2016-03-11 4:45 ` [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table Toshi Kani
2016-03-11 9:12 ` Borislav Petkov
2016-03-11 16:27 ` Toshi Kani
2016-03-11 15:54 ` Borislav Petkov
2016-03-11 19:28 ` Toshi Kani [this message]
2016-03-12 11:55 ` Borislav Petkov
2016-03-14 21:37 ` Toshi Kani
2016-03-15 11:00 ` Borislav Petkov
2016-03-15 22:02 ` Toshi Kani
2016-03-15 0:29 ` Luis R. Rodriguez
2016-03-15 3:11 ` Toshi Kani
2016-03-15 11:01 ` Borislav Petkov
2016-03-15 15:43 ` Toshi Kani
2016-03-15 15:47 ` Borislav Petkov
2016-03-15 17:11 ` Toshi Kani
2016-03-15 16:33 ` Borislav Petkov
2016-03-15 21:31 ` Luis R. Rodriguez
2016-03-11 4:45 ` [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Toshi Kani
2016-03-11 9:01 ` Ingo Molnar
2016-03-11 9:13 ` Ingo Molnar
2016-03-11 18:34 ` Toshi Kani
2016-03-12 16:18 ` Ingo Molnar
2016-03-14 19:47 ` Toshi Kani
2016-03-14 22:50 ` Luis R. Rodriguez
2016-03-15 0:37 ` Toshi Kani
2016-03-15 15:56 ` Borislav Petkov
2016-03-16 15:44 ` Joe Lawrence
2016-03-11 9:24 ` Borislav Petkov
2016-03-11 18:57 ` Toshi Kani
2016-03-11 22:17 ` Luis R. Rodriguez
2016-03-11 23:56 ` Toshi Kani
2016-03-11 23:34 ` Luis R. Rodriguez
2016-03-12 1:16 ` Toshi Kani
2016-03-15 0:15 ` Luis R. Rodriguez
2016-03-15 23:48 ` Toshi Kani
2016-03-15 23:29 ` Luis R. Rodriguez
2016-03-17 21:56 ` Toshi Kani
2016-03-18 0:06 ` Luis R. Rodriguez
2016-03-18 21:35 ` Toshi Kani
2016-03-29 17:14 ` Luis R. Rodriguez
2016-03-29 21:46 ` Toshi Kani
2016-03-29 22:12 ` Luis R. Rodriguez
2016-03-30 0:16 ` Toshi Kani
2016-03-29 23:43 ` Luis R. Rodriguez
2016-03-30 1:07 ` Toshi Kani
2016-03-30 0:34 ` Luis R. Rodriguez
2016-04-09 2:04 ` Luis R. Rodriguez
2016-04-11 14:30 ` Toshi Kani
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=1457724504.6393.151.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=mingo@kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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).