lkml.org 
[lkml]   [2019]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged
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

\
 
 \ /
  Last update: 2019-09-06 19:11    [W:0.142 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site