[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1458747975.6393.646.camel@hpe.com>
Date: Wed, 23 Mar 2016 09:46:15 -0600
From: Toshi Kani <toshi.kani@....com>
To: Borislav Petkov <bp@...e.de>
Cc: mingo@...nel.org, hpa@...or.com, tglx@...utronix.de,
mcgrof@...e.com, jgross@...e.com, paul.gortmaker@...driver.com,
konrad.wilk@...cle.com, elliott@....com, x86@...nel.org,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/6] x86/mm/pat: Change PAT to support non-default
PAT MSR
On Wed, 2016-03-23 at 09:43 +0100, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 12:35:19PM -0600, Toshi Kani wrote:
> > Right. Will change to "Add support of non-default PAT MSR setting at
> > handoff".
>
> Please remove this "handoff" notion from the text. Every hw register is
> being handed off to the OS once the kernel takes over so there's no need
> to make it special here.
Will do.
> > I'd like to make it clear that this function does not set PAT MSR,
> > unlike what pat_init() does. When CPU supports PAT, it keeps PAT MSR
> > in whatever the setting at handoff, and initializes PAT table to match
> > with this setting.
> >
> > I am open to a better name, but I am afraid that setup_pat() can be
> > confusing as if it sets PAT MSR.
>
> So call it init_cache_modes() and rename the current
> pat_init_cache_modes() to __init_cache_modes() to denote it is a lower
> level helper of the init_cache_modes() one. The init_cache_modes() one
> deals with the higher level figuring out of whether PAT is enabled and
> if not, preparing the attr bits for emulation. In the end, it calls
> __init_cache_modes(). All nice and easy.
Good idea! Will do.
Thanks,
-Toshi
Powered by blists - more mailing lists