Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750926AbcCVSUg (ORCPT ); Tue, 22 Mar 2016 14:20:36 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:40127 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750713AbcCVSUI (ORCPT ); Tue, 22 Mar 2016 14:20:08 -0400 Message-ID: <1458671719.6393.565.camel@hpe.com> Subject: Re: [PATCH v2 1/6] x86/mm/pat: Change PAT to support non-default PAT MSR From: Toshi Kani To: Borislav Petkov Cc: mingo@kernel.org, hpa@zytor.com, tglx@linutronix.de, mcgrof@suse.com, jgross@suse.com, paul.gortmaker@windriver.com, konrad.wilk@oracle.com, elliott@hpe.com, x86@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Date: Tue, 22 Mar 2016 12:35:19 -0600 In-Reply-To: <20160322165725.GB5656@pd.tnic> References: <1458175502-31936-1-git-send-email-toshi.kani@hpe.com> <1458175502-31936-2-git-send-email-toshi.kani@hpe.com> <20160322165725.GB5656@pd.tnic> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.4 (3.18.4-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2605 Lines: 74 On Tue, 2016-03-22 at 17:57 +0100, Borislav Petkov wrote: > $Subject is misleading - there's no non-default PAT MSR - the setting is > non-default. Right.  Will change to "Add support of non-default PAT MSR setting at handoff". > On Wed, Mar 16, 2016 at 06:44:57PM -0600, Toshi Kani wrote: > > In preparation to fix a regression caused by 'commit 9cd25aac1f44 > > ("x86/mm/pat: Emulate PAT when it is disabled")', PAT needs to > > support a case that PAT MSR is initialized with a non-default > > value. > > > > When pat_init() is called in PAT disable state, it initializes > >   is called and PAT is disabled Will do. > > PAT table with the BIOS default value. Xen, however, sets PAT MSR > > with a non-default value to enable WC. This causes inconsistency > > between PAT table and PAT MSR when PAT is set to disable on Xen. > > > > Change pat_init() to handle the PAT disable cases properly.  Add > > pat_keep_handoff_state() to handle two cases when PAT is set to > > disable. > >  1. CPU supports PAT: Set PAT table to be consistent with PAT MSR. > >  2. CPU does not support PAT: Set PAT table to be consistent with > >     PWT and PCD bits in a PTE. > >  : > > +/** > > + * pat_keep_handoff_state - Set PAT table to the handoff state > > + * > > + * This function keeps PAT in the BIOS handoff state. When CPU > > supports > > + * PAT, it sets PAT table to be consistent with PAT MSR. When CPU does > > not > > + * support PAT, it emulates PAT by setting PAT table consistent with > > PWT > > + * and PCD bits in a PTE. > > + * > > + * The PAT table is global to all CPUs, which is initialized once at > > + * boot-time. Any subsequent calls to this function have no effect. > > + */ > > +static void pat_keep_handoff_state(void) > > Static function, no need for "pat_" prefix. Also, no need for the > kernel-doc comment. > > Also, no need for all that handoff nomenclature etc, just call it > setup_pat(). Because it does exactly that - it sets up the PAT bits > unconditionally, regardless of enabled or not. 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. > >  { > > - u64 pat; > > - struct cpuinfo_x86 *c = &boot_cpu_data; > > + u64 pat = 0; > > + static int set_handoff_done; > > s/set_handoff_done/pat_setup_done/ I will match it with a func name once we decided. Thanks, -Toshi