From: Chao Gao <chao.gao@intel.com>
To: xen-devel@lists.xenproject.org
Cc: "Sergey Dyasli" <sergey.dyasli@citrix.com>,
"Ashok Raj" <ashok.raj@intel.com>, "Wei Liu" <wl@xen.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Chao Gao" <chao.gao@intel.com>,
"Brian Woods" <brian.woods@amd.com>,
"Suravee Suthikulpanit" <suravee.suthikulpanit@amd.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v10 00/16] improve late microcode loading
Date: Thu, 12 Sep 2019 15:22:13 +0800 [thread overview]
Message-ID: <1568272949-1086-1-git-send-email-chao.gao@intel.com> (raw)
Major changes in version 10:
- add back the patch to call wbinvd() conditionally
- add a patch to disable late loading due to BDF90
- rendezvous CPUs in NMI handler and load ucode. But provide an option
to disable this behavior.
- avoid the call of self_nmi() on the control thread because it may
trigger the unknown_nmi_error() in do_nmi().
- ensure ->start_update is called during system resuming from
suspension
Sergey, could you help to test this series on an AMD machine?
Regarding changes to AMD side, I didn't do any test for them due to
lack of hardware. At least, two basic tests are needed:
* do a microcode update after system bootup
* don't bring all pCPUs up at bootup by specifying maxcpus option in xen
command line and then do a microcode update and online all offlined
CPUs via 'xen-hptool'.
The intention of this series is to make the late microcode loading
more reliable by rendezvousing all cpus in stop_machine context.
This idea comes from Ashok. I am porting his linux patch to Xen
(see patch 12 more details).
This series includes below changes:
1. Patch 1-11: introduce a global microcode cache and some cleanup
2. Patch 12: synchronize late microcode loading
3. Patch 13: support parallel microcodes update on different cores
4. Patch 14: block #NMI handling during microcode loading
5. Patch 15: disable late ucode loading due to BDF90
6. Patch 16: call wbinvd() conditionally
Currently, late microcode loading does a lot of things including
parsing microcode blob, checking the signature/revision and performing
update. Putting all of them into stop_machine context is a bad idea
because of complexity (one issue I observed is memory allocation
triggered one assertion in stop_machine context). To simplify the
load process, parsing microcode is moved out of the load process.
Remaining parts of load process is put to stop_machine context.
Previous change log:
Changes in version 9:
- add Jan's Reviewed-by
- rendevzous threads in NMI handler to disable NMI. Note that NMI can
be served as usual on threads that are chosen to initiate ucode loading
on each core.
- avoid unnecessary memory allocation or copy when creating a microcode
patch (patch 12)
- rework patch 1 to avoid microcode_update_match() being used to
compare two arbitrary updates.
- call .end_update in early loading path.
Changes in version 8:
- block #NMI handling during microcode loading (Patch 16)
- Don't assume that all CPUs in the system have loaded a same ucode.
So when parsing a blob, we attempt to save a patch as long as it matches
with current cpu signature regardless of the revision of the patch.
And also for loading, we only require the patch to be loaded isn't old
than the cached one.
- store an update after the first successful loading on a CPU
- remove the patch that calls wbinvd() unconditionally before microcode
loading. It is under internal discussion.
- divide two big patches into several patches to improve readability.
Changes in version 7:
- cache one microcode update rather than a list of it. Assuming that all CPUs
(including those will be plugged in later) in the system have the same
signature, one update matches with one CPU should match with others. Thus, one
update is enough for microcode updating during CPU hot-plug and resuming.
- To handle load failure, microcode update is cached after it is applied to
avoid a broken update overriding a validated one. Unvalidated microcode updates
are passed by arguments rather than another global variable, where this series
slightly differs from Roger's suggestion in:
https://lists.xen.org/archives/html/xen-devel/2019-03/msg00776.html
- incorporate Sergey's patch (patch 10) to fix a bug: we maintain a variable
to reflect current microcode revision. But in some cases, this variable isn't
initialized during system boot time, which results in falsely reporting that
processor is susceptible to some known vulnerabilities.
- fix issues reported by Sergey:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg00901.html
- Responses to Sergey/Roger/Wei/Ashok's other comments.
Major changes in version 6:
- run wbinvd before updating microcode (patch 10)
- add an userspace tool for late microcode update (patch 1)
- scale time to wait by the number of remaining CPUs to respond
- remove 'cpu' parameters from some related callbacks and functins
- save an ucode patch only if its supported CPU is allowed to mix with
current cpu.
Changes in version 5:
- support parallel microcode updates for all cores (see patch 8)
- Address Roger's comments on the last version.
Chao Gao (16):
microcode/intel: extend microcode_update_match()
microcode/amd: distinguish old and mismatched ucode in
microcode_fits()
microcode: introduce a global cache of ucode patch
microcode: clean up microcode_resume_cpu
microcode: remove struct ucode_cpu_info
microcode: remove pointless 'cpu' parameter
microcode/amd: call svm_host_osvw_init() in common code
microcode: pass a patch pointer to apply_microcode()
microcode: split out apply_microcode() from cpu_request_microcode()
microcode: unify ucode loading during system bootup and resuming
microcode: reduce memory allocation and copy when creating a patch
x86/microcode: Synchronize late microcode loading
microcode: remove microcode_update_lock
microcode: rendezvous CPUs in NMI handler and load ucode
microcode: disable late loading if CPUs are affected by BDF90
microcode/intel: writeback and invalidate cache conditionally
docs/misc/xen-command-line.pandoc | 10 +
xen/arch/x86/acpi/power.c | 2 +-
xen/arch/x86/apic.c | 2 +-
xen/arch/x86/microcode.c | 569 ++++++++++++++++++++++++++++++--------
xen/arch/x86/microcode_amd.c | 282 +++++++++----------
xen/arch/x86/microcode_intel.c | 269 +++++++++++-------
xen/arch/x86/smpboot.c | 5 +-
xen/arch/x86/spec_ctrl.c | 2 +-
xen/arch/x86/traps.c | 6 +-
xen/include/asm-x86/microcode.h | 43 +--
xen/include/asm-x86/nmi.h | 3 +
xen/include/asm-x86/processor.h | 4 +-
12 files changed, 788 insertions(+), 409 deletions(-)
--
1.8.3.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next reply other threads:[~2019-09-12 7:19 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 7:22 Chao Gao [this message]
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 01/16] microcode/intel: extend microcode_update_match() Chao Gao
2019-09-12 10:24 ` Jan Beulich
2019-09-13 6:50 ` Jan Beulich
2019-09-13 7:02 ` Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 02/16] microcode/amd: distinguish old and mismatched ucode in microcode_fits() Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 03/16] microcode: introduce a global cache of ucode patch Chao Gao
2019-09-12 10:29 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 04/16] microcode: clean up microcode_resume_cpu Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 05/16] microcode: remove struct ucode_cpu_info Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 06/16] microcode: remove pointless 'cpu' parameter Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 07/16] microcode/amd: call svm_host_osvw_init() in common code Chao Gao
2019-09-12 12:34 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 08/16] microcode: pass a patch pointer to apply_microcode() Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 09/16] microcode: split out apply_microcode() from cpu_request_microcode() Chao Gao
2019-09-12 14:07 ` Jan Beulich
2019-09-13 6:47 ` Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 10/16] microcode: unify ucode loading during system bootup and resuming Chao Gao
2019-09-12 14:59 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 11/16] microcode: reduce memory allocation and copy when creating a patch Chao Gao
2019-09-12 15:04 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 12/16] x86/microcode: Synchronize late microcode loading Chao Gao
2019-09-12 15:32 ` Jan Beulich
2019-09-13 7:01 ` Chao Gao
2019-09-13 7:15 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 13/16] microcode: remove microcode_update_lock Chao Gao
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 14/16] microcode: rendezvous CPUs in NMI handler and load ucode Chao Gao
2019-09-13 9:14 ` Jan Beulich
2019-09-16 3:18 ` Chao Gao
2019-09-16 8:22 ` Jan Beulich
2019-09-13 9:18 ` Jan Beulich
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 15/16] microcode: disable late loading if CPUs are affected by BDF90 Chao Gao
2019-09-13 9:22 ` Jan Beulich
2019-09-17 9:01 ` Chao Gao
2019-09-17 10:49 ` Jan Beulich
2019-09-13 12:23 ` Andrew Cooper
2019-09-12 7:22 ` [Xen-devel] [PATCH v10 16/16] microcode/intel: writeback and invalidate cache conditionally Chao Gao
2019-09-13 9:32 ` Jan Beulich
2019-09-13 8:47 ` [Xen-devel] [PATCH v10 00/16] improve late microcode loading Jan Beulich
2019-09-17 7:09 ` Chao Gao
2019-09-17 7:11 ` Jan Beulich
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=1568272949-1086-1-git-send-email-chao.gao@intel.com \
--to=chao.gao@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=ashok.raj@intel.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brian.woods@amd.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=sergey.dyasli@citrix.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).