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:   Mon, 16 Sep 2019 12:36:11 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Raj, Ashok" <ashok.raj@intel.com>
cc:     Johannes Erdfelt <johannes@erdfelt.com>,
        Borislav Petkov <bp@alien8.de>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Mihai Carabas <mihai.carabas@oracle.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Jon Grimm <Jon.Grimm@amd.com>, kanth.ghatraju@oracle.com,
        konrad.wilk@oracle.com, patrick.colp@oracle.com,
        Tom Lendacky <thomas.lendacky@amd.com>,
        x86-ml <x86@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/microcode: Add an option to reload microcode even
 if revision is unchanged
In-Reply-To: <alpine.DEB.2.21.1909071236120.1902@nanos.tec.linutronix.de>
Message-ID: <alpine.DEB.2.21.1909161227060.10731@nanos.tec.linutronix.de>
References: <41cee473-321c-2758-032a-ccf0f01359dc@oracle.com> <D8A3D2BD-1FD4-4183-8663-3EF02A6099F3@alien8.de> <20190905002132.GA26568@otc-nc-03> <20190905072029.GB19246@zn.tnic> <20190905194044.GA3663@otc-nc-03> <alpine.DEB.2.21.1909052316130.1902@nanos.tec.linutronix.de>
 <20190905222706.GA4422@otc-nc-03> <alpine.DEB.2.21.1909061431330.1902@nanos.tec.linutronix.de> <20190906144039.GA29569@sventech.com> <alpine.DEB.2.21.1909062237580.1902@nanos.tec.linutronix.de> <20190907003338.GA14807@araj-mobl1.jf.intel.com>
 <alpine.DEB.2.21.1909071236120.1902@nanos.tec.linutronix.de>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, 7 Sep 2019, Thomas Gleixner wrote:
> 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?

That said, there is also a distinct lack of information about micro code
loading in a safe way in general. We absolutely do not know whether a micro
code update affects any instruction which might be in use during the update
on a sibling. Right now it's all load and pray and the SDM is not really
helpful with that either.

Thanks,

	tglx