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 S1752654AbdI2SlS (ORCPT <rfc822;w@1wt.eu>);
        Fri, 29 Sep 2017 14:41:18 -0400
Received: from merlin.infradead.org ([205.233.59.134]:52600 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752633AbdI2SlP (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 29 Sep 2017 14:41:15 -0400
Date: Fri, 29 Sep 2017 20:41:04 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Mike Travis <mike.travis@hpe.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Bin Gao <bin.gao@linux.intel.com>, Prarit Bhargava <prarit@redhat.com>,
        Dimitri Sivanich <dimitri.sivanich@hpe.com>,
        Andrew Banman <andrew.banman@hpe.com>,
        Russ Anderson <russ.anderson@hpe.com>, linux-kernel@vger.kernel.org,
        x86@kernel.org, kevin.b.stanton@intel.com
Subject: Re: [PATCH 0/4] x86/platform/UV: Update TSC support
Message-ID: <20170929184104.GX6524@worktop.programming.kicks-ass.net>
References: <20170928180339.010141096@stormcage.americas.sgi.com>
 <20170929084632.gfwugbeaonraadp3@hirez.programming.kicks-ass.net>
 <df8cabdd-a5f9-9e2d-b089-cf0f3dbe16eb@hpe.com>
 <20170929162350.adakhwxsqyq2ff2f@hirez.programming.kicks-ass.net>
 <bedd5a84-34d9-a13b-4b0d-7188d6f8629f@hpe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bedd5a84-34d9-a13b-4b0d-7188d6f8629f@hpe.com>
User-Agent: Mutt/1.5.22.1 (2013-10-16)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Sep 29, 2017 at 10:39:28AM -0700, Mike Travis wrote:
> >That's where it comes from. But normal systems really _should_ have it
> >at 0 and its a useful sanity check IMO. We really want to know when the
> >BIOS does a funny behind our backs.
> >
> 
> How about a more generic flag, such as "multi_tsc_sync_sources"?  That could
> trigger both disabling the "TSC == 0 on socket 0" check as well as disabling
> X86_FEATURE_ART where appropriate?  Or I could clear the feature ART cap
> separately in the UV system init code if they are not really related?

I _think_ the X86_FEATURE_ART is an artificial flag. We key off of
cpuid_level here.

So that multi_tsc_sync_sources or a more explicit is_uv_system() would
be required.