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:   Fri, 6 Sep 2019 12:43:53 -0400
From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Johannes Erdfelt <johannes@erdfelt.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        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,
        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
Message-ID: <20190906164353.GB2840@char.us.oracle.com>
References: <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>
 <20190906151617.GE19008@zn.tnic>
 <20190906154618.GB29569@sventech.com>
 <20190906161735.GH19008@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190906161735.GH19008@zn.tnic>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Or someone could rewrite arch/x86/ to rediscover new features upon a
> microcode reload or a feature disabling. And do that in a clean way. Who
> knows...

The clean way to do microcode reloading and the vast amount of re-initialization
that has to happen is the definitly what we all want.

It may not surprise you that we have tinkered with this, but what we have
is very far from 'clean'.

Do you have insights on the best way to restructure the code for this?

..snip..

> Practically speaking, late loading probably won't disappear as it is
> being used apparently. Just don't expect that it will get "extended" if
> that extension brings with itself fallout and duct tape fixes left and
> right.

We don't want duct-tape.

I am hoping you can help in figuring out a way that will be acceptable.

We did an analysis of some of the the things that we would need to address
to make this work, but sadly it only covered the "oh crud, this has to
be thought off", but not the overall architecture.