Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756113AbcCNUo4 (ORCPT ); Mon, 14 Mar 2016 16:44:56 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:33260 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752817AbcCNUox (ORCPT ); Mon, 14 Mar 2016 16:44:53 -0400 Message-ID: <1457991443.6393.290.camel@hpe.com> Subject: Re: [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table 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" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" Date: Mon, 14 Mar 2016 15:37:23 -0600 In-Reply-To: <20160312115544.GA23410@pd.tnic> References: <1457671546-13486-1-git-send-email-toshi.kani@hpe.com> <1457671546-13486-2-git-send-email-toshi.kani@hpe.com> <20160311091229.GA4347@pd.tnic> <1457713660.6393.55.camel@hpe.com> <20160311155439.GF4312@pd.tnic> <1457724504.6393.151.camel@hpe.com> <20160312115544.GA23410@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: 1368 Lines: 35 On Sat, 2016-03-12 at 12:55 +0100, Borislav Petkov wrote: > Ok, let's start again. > > So what's wrong with this simpler, cleaner version below? > > * It makes sure to run the rendezvous handler on the BP on init. > > * It disables PAT otherwise. > > * Oh, and it boots fine with Paul's reproducer, X is there (even though > vncviewer dies when X starts with "Rect too large: 640x480 at (0, 0)" > and I have to reconnect to see the X window). > > In dmesg I see "x86/PAT: Disabled by MTRR". Your patch is a simplified version of mine.  So, yes, it fixes the Paul's issue, but it does not address other issues that my patchset also addressed.  In specific, I think your patch has the following issues. - pat_disable() is now callable from other modules. So, it needs to check with boot_cpu_done. We cannot disable PAT once it is initialized. - mtrr_bp_init() needs to check with mtrr_enabled() when it calls mtrr_pat_setup_bp(). Otherwise, PAT is left initialized on BSP only when MTRR is disabled by its MSR. In your patch, mtrr_bp_init() calls pat_setup() again, but it does not help since boot_cpu_done is set. - When PAT is disabled in CPU feature, pat_bsp_init() calls pat_disable() and returns. However, it does not initialize a PAT table by calling pat_init_cache_modes(). - When CONFIG_MTRR is unset, it does not call pat_setup(). Thanks, -Toshi