Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3242680ybe; Sun, 8 Sep 2019 09:59:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDXJIOuHkPiiJUeCsOc8Y5oFs4WbTPbVpN3nYijil9a3LMgmJ4i1qjUCsfwo8/IvLL4ta3 X-Received: by 2002:a17:906:8406:: with SMTP id n6mr16141823ejx.138.1567961956969; Sun, 08 Sep 2019 09:59:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567961956; cv=none; d=google.com; s=arc-20160816; b=mWrSKeWUj3x8S81bstlZFeEenqYi2W2RciEod3uV8A2eQStYNaOlJsRGqVxgG81LCC pyFYNPSAO4c26nUGyRqvPcXShlKqt4OpTmVEfVJsRUuKQ8cqcUSI3f1D0YKY8PKp9PH9 EWkXM8GDX2rKss71q5KIElF74N+JPQJGedYMOi1ACJkDZuGSKhdsZNTyvJhwT6y6OWpm GRmHuiWJJCARjYsFo7lVegGRWn1gSU7QQLH4gfsOTvRXCDzsvjevOer8grZTnu6od1ex qXDg3MOH5SiEDckzh+SkZg6esCo8VBAO03lMKNzIqEbmgKmyNVqpe/Vyv76LbTr3T+x/ XFZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=vhKYOQcB7mBEcL8NPv+xa/qwBOSuzQWKy+q/S/2Q09w=; b=RJ4ScXhIdDAU8UvIIQjiTH1GaSIJb7AAlKtKUiADy+8nQdQJKDshoY6pITLJp0cSgz wACJvKT1ugI2v3DMexY+p+dHEBMVFC7BFYw5/Asy8bD7JiJuONpELQhy++9JcrzFYywK KDHUNO+xEd07A6t32Q5U2TLOebkl1qL0Us2ob2/kA41eqFBuoJe9sz3yXvjMvfVyefDb +kRaa7KHiJFeJNMyOiD8MiFfxieFQW7NR6IKAESPjLUa7Aogh8utqk/5prtTpr9B+ERM +7/18Y6mYWazMATMbL6yA5iACNdHJAY2RQ18SuF2RHsLgNKA9pA3EWtpE22uMVke5m9s TdrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si6129159edr.36.2019.09.08.09.58.53; Sun, 08 Sep 2019 09:59:16 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388522AbfIGKhh (ORCPT + 99 others); Sat, 7 Sep 2019 06:37:37 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:49183 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726027AbfIGKhg (ORCPT ); Sat, 7 Sep 2019 06:37:36 -0400 Received: from p5de0b6c5.dip0.t-ipconnect.de ([93.224.182.197] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1i6Y5g-00053B-Ps; Sat, 07 Sep 2019 12:37:12 +0200 Date: Sat, 7 Sep 2019 12:37:11 +0200 (CEST) From: Thomas Gleixner To: "Raj, Ashok" cc: Johannes Erdfelt , Borislav Petkov , Boris Ostrovsky , Mihai Carabas , "H. Peter Anvin" , Ingo Molnar , Jon Grimm , kanth.ghatraju@oracle.com, konrad.wilk@oracle.com, patrick.colp@oracle.com, Tom Lendacky , x86-ml , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged In-Reply-To: <20190907003338.GA14807@araj-mobl1.jf.intel.com> Message-ID: References: <41cee473-321c-2758-032a-ccf0f01359dc@oracle.com> <20190905002132.GA26568@otc-nc-03> <20190905072029.GB19246@zn.tnic> <20190905194044.GA3663@otc-nc-03> <20190905222706.GA4422@otc-nc-03> <20190906144039.GA29569@sventech.com> <20190907003338.GA14807@araj-mobl1.jf.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 6 Sep 2019, Raj, Ashok wrote: > On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote: > > Now #1 is actually a sensible and feasible solution which can be pulled off > > in a reasonably short time frame, avoids all the bound to be ugly and > > failure laden attempts of fixing late loading completely and provides a > > usable and safe solution for joe user, jack admin and the super experts at > > big-cloud corporate. > > > > That is not requiring any new format of microcode payload, as this can be > > nicely done as a metadata package which comes with the microcode > > payload. So you get the following backwards compatible states: > > > > Kernel metadata result > > > > old don't care refuse late load > > > > new No refuse late load > > > > new Yes decide based on metadata > > > > Thoughts? > > This is 100% in line with what we proposed... So what it hindering you to implement that? ucode teams whining about the little bit of extra work? Thanks, tglx