From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932691AbeAJBoH (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Tue, 9 Jan 2018 20:44:07 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:54003 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932412AbeAJBoG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 9 Jan 2018 20:44:06 -0500
Date: Wed, 10 Jan 2018 02:44:02 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Hansen <dave.hansen@intel.com>
cc: LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linuxfoundation.org>, x86@kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Borislav Petkov <bp@alien8.de>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andi Kleen <ak@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andy Lutomirski <luto@kernel.org>,
        Arjan Van De Ven <arjan.van.de.ven@intel.com>,
        Borislav Petkov <bp@suse.de>,
        "Raj, Ashok" <ashok.raj@intel.com>
Subject: Re: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late
In-Reply-To: <f70ea6ad-d563-5f60-2657-0551249a70e6@intel.com>
Message-ID: <alpine.DEB.2.20.1801100242550.2200@nanos>
References: <20180110010652.404145126@linutronix.de> <20180110011350.501418723@linutronix.de> <f70ea6ad-d563-5f60-2657-0551249a70e6@intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

On Tue, 9 Jan 2018, Dave Hansen wrote:

> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > This is for the case where we need to set feature flags late, like, for
> > example, after late microcode patch has been loaded which has enabled
> > new CPUID bits.
> > 
> > This has no effect on alternatives patching.
> 
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
> 
> I'll also profess some microcode ignorance here.  Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?

IBRS wont use alternatives for that and various other reasons. It has to be
static key based so we can patch it late

Thanks,

	tglx