From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751824AbcJIOGc (ORCPT <rfc822;w@1wt.eu>);
        Sun, 9 Oct 2016 10:06:32 -0400
Received: from mga03.intel.com ([134.134.136.65]:47329 "EHLO mga03.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751130AbcJIOGb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 9 Oct 2016 10:06:31 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,466,1473145200"; 
   d="scan'208";a="1062469429"
Date: Sun, 9 Oct 2016 10:09:37 -0700
From: Fenghua Yu <fenghua.yu@intel.com>
To: Borislav Petkov <bp@suse.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H. Peter Anvin" <h.peter.anvin@intel.com>,
        Ingo Molnar <mingo@elte.hu>, Tony Luck <tony.luck@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Stephane Eranian <eranian@google.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Nilay Vaish <nilayvaish@gmail.com>, Shaohua Li <shli@fb.com>,
        David Carrillo-Cisneros <davidcc@google.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        Sai Prakhya <sai.praneeth.prakhya@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v3 07/18] x86/intel_rdt: Add Haswell feature discovery
Message-ID: <20161009170936.GC7672@linux.intel.com>
References: <1475894763-64683-1-git-send-email-fenghua.yu@intel.com>
 <1475894763-64683-8-git-send-email-fenghua.yu@intel.com>
 <20161009114116.js3cevxzbuucjeni@pd.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161009114116.js3cevxzbuucjeni@pd.tnic>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Oct 09, 2016 at 01:41:16PM +0200, Borislav Petkov wrote:
> On Fri, Oct 07, 2016 at 07:45:52PM -0700, Fenghua Yu wrote:
> > From: Fenghua Yu <fenghua.yu@intel.com>
> > 
> > Some Haswell generation CPUs support RDT, but they don't enumerate this
> > using CPUID.  Use rdmsr_safe() and wrmsr_safe() to probe the MSRs on
> > cpu model 63 (INTEL_FAM6_HASWELL_X)
> > 
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > Signed-off-by: Tony Luck <tony.luck@intel.com>
> > ---
> >  arch/x86/events/intel/cqm.c             |  2 +-
> >  arch/x86/include/asm/intel_rdt_common.h |  6 ++++++
> >  arch/x86/kernel/cpu/intel_rdt.c         | 38 +++++++++++++++++++++++++++++++++
> >  3 files changed, 45 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/x86/include/asm/intel_rdt_common.h
> 
> ...
> 
> > +static inline bool cache_alloc_hsw_probe(void)
> > +{
> > +	u32 l, h_old, h_new, h_tmp;
> > +
> > +	if (rdmsr_safe(MSR_IA32_PQR_ASSOC, &l, &h_old))
> > +		return false;
> > +
> > +	/*
> > +	 * Default value is always 0 if feature is present.
> > +	 */
> > +	h_tmp = h_old ^ 0x1U;
> > +	if (wrmsr_safe(MSR_IA32_PQR_ASSOC, l, h_tmp))
> 
> I don't understand - you do the family/model check below and yet still
> use the _safe() variants. Isn't the presence of that MSR guaranteed on
> those machines?

The MSR is not guaranteed on every stepping of the family and model machine
because some parts may have the MSR fused off. And some bits in the MSR
may not be implemented on some parts. And in KVM or guest, the MSR may not
implemented. Those are reasons why we use wrmsr_safe/rdmsr_safe in Haswell
probe.

Thanks.

-Fenghua