From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932910AbcCKWRv (ORCPT ); Fri, 11 Mar 2016 17:17:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:59506 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932084AbcCKWRt (ORCPT ); Fri, 11 Mar 2016 17:17:49 -0500 Date: Fri, 11 Mar 2016 23:17:47 +0100 From: "Luis R. Rodriguez" To: Toshi Kani Cc: Borislav Petkov , mingo@kernel.org, hpa@zytor.com, tglx@linutronix.de, jgross@suse.com, paul.gortmaker@windriver.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code Message-ID: <20160311221747.GC25147@wotan.suse.de> References: <1457671546-13486-1-git-send-email-toshi.kani@hpe.com> <1457671546-13486-3-git-send-email-toshi.kani@hpe.com> <20160311092400.GB4347@pd.tnic> <1457722632.6393.130.camel@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1457722632.6393.130.camel@hpe.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 11, 2016 at 11:57:12AM -0700, Toshi Kani wrote: > On Fri, 2016-03-11 at 10:24 +0100, Borislav Petkov wrote: > > On Thu, Mar 10, 2016 at 09:45:46PM -0700, Toshi Kani wrote: > > > MTRR manages PAT initialization as it implements a rendezvous > > > handler that initializes PAT as part of MTRR initialization. > > > > > > When CPU does not support MTRR, ex. qemu32 virtual CPU, MTRR > > > simply skips PAT init, which causes PAT left enabled without > > > initialization.  Also, get_mtrr_state() calls pat_init() on > > > BSP even if MTRR is disabled by its MSR.  This causes pat_init() > > > be called on BSP only. > > > > So I don't understand what all this hoopla is all about: why can't you > > simply call pat_disable() in mtrr_ap_init() and be done with it? > > > > void mtrr_ap_init(void) > > { > >         if (!mtrr_enabled()) { > > pat_disable(); > >                 return; > > } > > > > ? > > No, it does not fix it. The problem in this particular case, i.e. MTRR > disabled by its MSR, is that mtrr_bp_init() calls pat_init() (as PAT > enabled) and initializes PAT on BSP. After APs are launched, we need the > MTRR's rendezvous handler to initialize PAT on APs to be consistent with > BSP. However, MTRR rendezvous handler is no-op since MTRR is disabled. This seems like a hack on enabling PAT through MTRR code, can we have a PAT rendezvous handler on its own, or provide a generic rendezvous handler that lets you deal with whatever interfaces need setup. Then conflicts can just be negotiated early. What I'm after is seeing if we can ultimately disable MTRR on kernel code but still have PAT enabled. I realize you've mentioned BIOS code may use some MTRR setup code but this is only true for some systems. I know for a fact Xen cannot use MTRR, it seems qemu32 does not enable it either. So why not have the ability to skip through its set up ? I'll also note Xen managed to enable PAT only without enabling MTRR, this was done through pat_init_cache_modes() -- not sure if this can be leveraged for qemu32... Luis