[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1458684133.6393.630.camel@hpe.com>
Date: Tue, 22 Mar 2016 16:02:13 -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 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is
disabled
On Tue, 2016-03-22 at 18:01 +0100, Borislav Petkov wrote:
> Subject: [PATCH v2 4/6] x86/mtrr: Fix PAT init handling when MTRR MSR is
> disabled
>
> s/ MSR//
Will do.
> On Wed, Mar 16, 2016 at 06:46:57PM -0600, Toshi Kani wrote:
> > get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled
> > by its MSR.
>
> s/by its MSR//
Will do.
> > This causes pat_init() to be called on BSP only since APs do not call
>
> This doesn't cause that - get_mtrr_state() is called only on the BSP by
> mtrr_bp_init().
Right, I will change it to "results" or something.
> > pat_init() when MTRR is disabled. This inconsistency between BSP and
> > APs leads undefined behavior.
>
> leads to
Will do.
> > Move BSP's PAT init code from get_mtrr_state() to mtrr_bp_pat_init().
> > Change mtrr_bp_init() to call mtrr_bp_pat_init() if MTRR is enabled.
>
> No need for those.
OK.
> > This keeps BSP's calling condition to pat_init() consistent with AP's,
> > mtrr_ap_init() and mtrr_aps_init().
>
> This one is fine.
:-)
Thanks,
-Toshi
Powered by blists - more mailing lists