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
Date: Fri, 6 Sep 2019 12:43:53 -0400 [thread overview]
Message-ID: <20190906164353.GB2840@char.us.oracle.com> (raw)
In-Reply-To: <20190906161735.GH19008@zn.tnic>
> 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.
next prev parent reply other threads:[~2019-09-06 16:42 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 [this message]
2019-09-06 17:10 ` Borislav Petkov
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=20190906164353.GB2840@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=Jon.Grimm@amd.com \
--cc=ashok.raj@intel.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=johannes@erdfelt.com \
--cc=kanth.ghatraju@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