From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965054AbeAJLDG (ORCPT + 1 other); Wed, 10 Jan 2018 06:03:06 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:55327 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbeAJLDE (ORCPT ); Wed, 10 Jan 2018 06:03:04 -0500 Date: Wed, 10 Jan 2018 12:02:54 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: "Van De Ven, Arjan" , "Hansen, Dave" , LKML , Linus Torvalds , "x86@kernel.org" , Peter Zijlstra , Borislav Petkov , David Woodhouse , Tim Chen , Andrea Arcangeli , Andi Kleen , Greg KH , Andy Lutomirski , Borislav Petkov , "Raj, Ashok" Subject: Re: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late In-Reply-To: <96FD6D6D-4D56-492F-A996-F18F913F5091@amacapital.net> Message-ID: References: <20180110010652.404145126@linutronix.de> <20180110011350.501418723@linutronix.de> <0575AF4FD06DD142AD198903C74E1CC87A571BD8@ORSMSX103.amr.corp.intel.com> <96FD6D6D-4D56-492F-A996-F18F913F5091@amacapital.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, 9 Jan 2018, Andy Lutomirski wrote: > > On Jan 9, 2018, at 5:47 PM, Thomas Gleixner wrote: > > > > On Wed, 10 Jan 2018, Van De Ven, Arjan wrote: > >>> 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? > >> > >> the early boot loader level stuff is much better generally (but does not > >> work when the microcode comes out after the system booted... like really > >> long uptimes) > > > > That stuff indeed would be way simpler w/o the late support, but the fact > > that the microcode for this might reach the user way later than the kernel > > support makes it almost a must to support the late loading. > > How hard would it be to add a late alternative feature? Concretely, we'd > have a list of "late" cpufeatures. When we scan the alternative list, if > we find a late feature, we copy it to some other list that isn't > discarded, and we also copy its replacement (and relocate it eagerly, > since we'll lose the offset). It shouldn't be rocket science, but that's not for now. And yes, we should do it. Thanks, tglx