Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Jul 2018 17:07:42 -0300
From:   Eduardo Habkost <ehabkost@redhat.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Dave Hansen <dave.hansen@intel.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Ingo Molnar <mingo@redhat.com>, H Peter Anvin <hpa@zytor.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Alan Cox <alan@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Rafael Wysocki <rafael.j.wysocki@intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split
 locked access feature
Message-ID: <20180704200742.GD7451@localhost.localdomain>
References: <1530282807-66555-1-git-send-email-fenghua.yu@intel.com>
 <1530282807-66555-2-git-send-email-fenghua.yu@intel.com>
 <b0267bb2-7d1f-c1d6-cff8-addf358009b3@intel.com>
 <alpine.DEB.2.21.1806291813570.1595@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1806291813570.1595@nanos.tec.linutronix.de>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 29, 2018 at 06:23:35PM +0200, Thomas Gleixner wrote:
> On Fri, 29 Jun 2018, Dave Hansen wrote:
> > On 06/29/2018 07:33 AM, Fenghua Yu wrote:
> > > +/* Detect feature of #AC for split lock by probing bit 29 in MSR_TEST_CTL. */
> > > +void detect_ac_split_lock(void)
> > > +{
> > > +	u64 val, orig_val;
> > > +	int ret;
> > > +
> > > +	/* Attempt to read the MSR. If the MSR doesn't exist, reading fails. */
> > > +	ret = rdmsrl_safe(MSR_TEST_CTL, &val);
> > > +	if (ret)
> > > +		return;
> > 
> > This is a bit fast and loose with how the feature is detected, which
> > might be OK, but can we call out why we are doing this, please?
> > 
> > Is this MSR not really model-specific?  Is it OK to go poking at it on
> > all x86 variants?  Or, do we at _least_ need a check for Intel cpus in here?
> 
> That definitely needs a vendor check. Also the whole code needs to be
> compiled out if CONFIG_INTEL=n.
> 
> Aside of that this wants to be enumerated. CPUID or MISC_FEATURES and not
> this guess work detection logic. Why do I have to ask for that for every
> other new feature thingy?

Yes, please.  KVM hosts normally expect guests to not touch MSRs
unless we explicitly tell them the MSR is available (normally
through CPUID).  This is important to ensure live migration
between different host kernel versions works reliably.

-- 
Eduardo