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
Date: Fri, 6 Sep 2019 19:10:12 +0200 [thread overview]
Message-ID: <20190906171012.GK19008@zn.tnic> (raw)
In-Reply-To: <20190906164353.GB2840@char.us.oracle.com>
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
next prev parent reply other threads:[~2019-09-06 17:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 5:33 [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged Ashok Raj
2019-08-29 5:38 ` Raj, Ashok
2019-08-29 6:09 ` Borislav Petkov
2019-08-29 13:02 ` Raj, Ashok
2019-09-03 16:46 ` Borislav Petkov
2019-09-04 22:06 ` Boris Ostrovsky
2019-09-04 22:12 ` Boris Petkov
2019-09-05 0:21 ` Raj, Ashok
2019-09-05 7:20 ` Borislav Petkov
2019-09-05 10:51 ` Thomas Gleixner
2019-09-05 19:40 ` Raj, Ashok
2019-09-05 19:49 ` Borislav Petkov
2019-09-05 20:20 ` Raj, Ashok
2019-09-05 21:22 ` Thomas Gleixner
2019-09-05 22:27 ` Raj, Ashok
2019-09-06 7:46 ` Borislav Petkov
2019-09-06 12:51 ` Thomas Gleixner
2019-09-06 14:40 ` Johannes Erdfelt
2019-09-06 15:16 ` Borislav Petkov
2019-09-06 15:46 ` Johannes Erdfelt
2019-09-06 16:17 ` Borislav Petkov
2019-09-06 16:43 ` Konrad Rzeszutek Wilk
2019-09-06 17:10 ` Borislav Petkov [this message]
2019-09-06 16:52 ` Johannes Erdfelt
2019-09-06 17:17 ` Borislav Petkov
2019-09-06 21:16 ` Thomas Gleixner
2019-09-07 0:33 ` Raj, Ashok
2019-09-07 10:37 ` Thomas Gleixner
2019-09-16 10:36 ` Thomas Gleixner
2019-09-17 0:31 ` Raj, Ashok
2019-09-17 6:37 ` Thomas Gleixner
2019-09-17 6:46 ` Borislav Petkov
2019-09-17 14:29 ` Raj, Ashok
2019-09-19 19:48 ` Mihai Carabas
2019-09-06 16:55 ` Raj, Ashok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190906171012.GK19008@zn.tnic \
--to=bp@alien8.de \
--cc=Jon.Grimm@amd.com \
--cc=ashok.raj@intel.com \
--cc=boris.ostrovsky@oracle.com \
--cc=hpa@zytor.com \
--cc=johannes@erdfelt.com \
--cc=kanth.ghatraju@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mihai.carabas@oracle.com \
--cc=mingo@redhat.com \
--cc=patrick.colp@oracle.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox