[Xen-devel] [PATCH v6 00/12] improve late microcode loading

[Chao Gao <chao.gao@xxxxxxxxx>]

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.

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 10 and 11 for more details).

This series makes five changes:
 1. Patch 1: an userspace tool for late microcode update
 2. Patch 2-9: introduce a global microcode cache and some cleanup
 3. Patch 10: writeback and invalidate cache before updating microcode
 3. Patch 11: synchronize late microcode loading
 4. Patch 12: support parallel microcodes update on different cores

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). In order to simplify
the load process, I move parsing microcode out of the load process.
The microcode blob is parsed and a global microcode cache is built on
a single CPU before rendezvousing all cpus to update microcode. Other
CPUs just get and load a suitable microcode from the global cache.
With this global cache, it is safe to put simplified load process to
stop_machine context.

Regarding changes to AMD side, I didn't do any test for them due to
lack of hardware. Could you help to test this series on an AMD machine?
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'.

Chao Gao (12):
  misc/xenmicrocode: Upload a microcode blob to the hypervisor
  microcode/intel: use union to get fields without shifting and masking
  microcode/intel: extend microcode_update_match()
  microcode: introduce a global cache of ucode patch
  microcode: only save compatible ucode patches
  microcode: remove struct ucode_cpu_info
  microcode: remove pointless 'cpu' parameter
  microcode: split out apply_microcode() from cpu_request_microcode()
  microcode: remove struct microcode_info
  microcode/intel: Writeback and invalidate caches before updating
    microcode
  x86/microcode: Synchronize late microcode loading
  microcode: update microcode on cores in parallel

 tools/libxc/include/xenctrl.h   |   1 +
 tools/libxc/xc_misc.c           |  20 +++
 tools/misc/Makefile             |   4 +
 tools/misc/xenmicrocode.c       |  89 ++++++++++
 xen/arch/x86/acpi/power.c       |   2 +-
 xen/arch/x86/apic.c             |   2 +-
 xen/arch/x86/microcode.c        | 380 +++++++++++++++++++++++++++-------------
 xen/arch/x86/microcode_amd.c    | 236 ++++++++++++-------------
 xen/arch/x86/microcode_intel.c  | 206 +++++++++++++---------
 xen/arch/x86/smpboot.c          |   5 +-
 xen/arch/x86/spec_ctrl.c        |   2 +-
 xen/include/asm-x86/microcode.h |  40 +++--
 xen/include/asm-x86/processor.h |   3 +-
 13 files changed, 639 insertions(+), 351 deletions(-)
 create mode 100644 tools/misc/xenmicrocode.c

-- 
1.8.3.1


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel