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 19:10:12 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
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: <20190906171012.GK19008@zn.tnic>
References: <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>
 <20190906164353.GB2840@char.us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190906164353.GB2840@char.us.oracle.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 06, 2019 at 12:43:53PM -0400, Konrad Rzeszutek Wilk wrote:
> Do you have insights on the best way to restructure the code for this?

Well, I only started thinking about this when you guys brought it on and
you were actually serious about it. :)

So IINM, this is one of the livepatch problems where the universe before
the patching and after the patching needs to be consistent, so to speak.

But how do you handle the case where feature detection has happened, a
bunch of code is active now and running because the feature is there and
then you disable that feature and all that code does what? And what do
you tell the user programs which are using it?

Sounds a lot like a reboot to me. :-P

Was the code programmed with the ability to be gracefully disabled at
any point in time, in mind? I doubt that. I don't think any of the CPU
feature supporting code has been programmed to be disabled at arbitrary
points in time.

Now, can you do something like suspend the CPUs, disable some
features and resume them and make them re-detect it all again and act
accordingly?

Sure, we do some of that but not comprehensively...

So my gut feeling is this is just the tip of the iceberg and the devil
is in the detail and all sorts of similar proverbs.

Best guess would be, try to do it and see what kinds of problems you
encounter and try to fix them cleanly. I betcha you'll be busy a long
time...

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette