From patchwork Mon May 27 08:31:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chao Gao X-Patchwork-Id: 10962285 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2120791E for ; Mon, 27 May 2019 08:29:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1279328AAC for ; Mon, 27 May 2019 08:29:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0570828AB7; Mon, 27 May 2019 08:29:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7E96028AAC for ; Mon, 27 May 2019 08:29:36 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hVAyc-00049Y-0R; Mon, 27 May 2019 08:27:26 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hVAya-00049T-Py for xen-devel@lists.xenproject.org; Mon, 27 May 2019 08:27:24 +0000 X-Inumbo-ID: 4023e8bb-8059-11e9-8980-bc764e045a96 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 4023e8bb-8059-11e9-8980-bc764e045a96; Mon, 27 May 2019 08:27:23 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2019 01:27:22 -0700 X-ExtLoop1: 1 Received: from gao-cwp.sh.intel.com ([10.239.159.26]) by orsmga005.jf.intel.com with ESMTP; 27 May 2019 01:27:19 -0700 From: Chao Gao To: xen-devel@lists.xenproject.org Date: Mon, 27 May 2019 16:31:21 +0800 Message-Id: <1558945891-3015-1-git-send-email-chao.gao@intel.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v7 00/10] improve late microcode loading X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sergey Dyasli , Ashok Raj , Wei Liu , Andrew Cooper , Jan Beulich , Boris Ostrovsky , Chao Gao , Brian Woods , Suravee Suthikulpanit , =?utf-8?q?Roger_Pau_?= =?utf-8?q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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. 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 7 and 8 for more details). This series includes five changes: 1. Patch 1: an userspace tool for late microcode update 2. Patch 2-6: introduce a global microcode cache and some cleanup 3. Patch 7: writeback and invalidate cache before updating microcode 3. Patch 8: synchronize late microcode loading 4. Patch 9: support parallel microcodes update on different cores 5. Patch 10: always read microcode revision at boot time 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. Regarding changes to AMD side, I didn't do any test for them due to lack of hardware. Sergey, could you help to test this series on an AMD machine again? 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 (9): misc/xen-ucode: Upload a microcode blob to the hypervisor microcode/intel: extend microcode_update_match() microcode: introduce a global cache of ucode patch microcode: remove struct ucode_cpu_info microcode: remove pointless 'cpu' parameter microcode: split out apply_microcode() from cpu_request_microcode() microcode/intel: Writeback and invalidate caches before updating microcode x86/microcode: Synchronize late microcode loading microcode: remove microcode_update_lock Sergey Dyasli (1): x86/microcode: always collect_cpu_info() during boot tools/libxc/include/xenctrl.h | 1 + tools/libxc/xc_misc.c | 23 +++ tools/misc/Makefile | 4 + tools/misc/xen-ucode.c | 78 ++++++++ xen/arch/x86/acpi/power.c | 2 +- xen/arch/x86/apic.c | 2 +- xen/arch/x86/microcode.c | 401 ++++++++++++++++++++++++++++------------ xen/arch/x86/microcode_amd.c | 245 ++++++++++++------------ xen/arch/x86/microcode_intel.c | 202 ++++++++++---------- xen/arch/x86/smpboot.c | 5 +- xen/arch/x86/spec_ctrl.c | 2 +- xen/include/asm-x86/microcode.h | 39 ++-- xen/include/asm-x86/processor.h | 3 +- 13 files changed, 639 insertions(+), 368 deletions(-) create mode 100644 tools/misc/xen-ucode.c