From patchwork Wed Nov 27 10:04:30 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Sergey Dyasli X-Patchwork-Id: 11263683 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4A5D513A4 for ; Wed, 27 Nov 2019 10:05:54 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 249AF2070A for ; Wed, 27 Nov 2019 10:05:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="QcmKGBKn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 249AF2070A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iZuBg-00035W-Nl; Wed, 27 Nov 2019 10:04:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iZuBg-00035R-5D for xen-devel@lists.xen.org; Wed, 27 Nov 2019 10:04:44 +0000 X-Inumbo-ID: 552175ba-10fd-11ea-a55d-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 552175ba-10fd-11ea-a55d-bc764e2007e4; Wed, 27 Nov 2019 10:04:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1574849083; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=uSrzHUWCoWXcqtCfA18dvQxmWOKDnC44dG31TcoPTRA=; b=QcmKGBKnbGheggEmpAguBFx71aR73VoiCjiC362FXBRgxvJOmye6rVmb 8UQPrbqnK450Lv7DdzSXKo6oT83ygE6LzXjOgXVulYB1OvhWFVAAbCQP/ KTN72iRhvi6wQdkCOO6fXkFIzlobqaBfV83/dbOTEMnInyFP8Nbbx9OKJ 0=; Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=sergey.dyasli@citrix.com; spf=Pass smtp.mailfrom=sergey.dyasli@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender authenticity information available from domain of sergey.dyasli@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="sergey.dyasli@citrix.com"; x-sender="sergey.dyasli@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa4.hc3370-68.iphmx.com: domain of sergey.dyasli@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="sergey.dyasli@citrix.com"; x-sender="sergey.dyasli@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa4.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa4.hc3370-68.iphmx.com; envelope-from="sergey.dyasli@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: b+h+C5C4vdN10WKrLLULcdhN3YX8vDrzhoks+kSUaHAYAK7FLOLnBGzB8EaHalAoHNCPlBw87E 6kqQTlMo/Iz8RvtzUaLBUSof22WkOjko65ru1SHWO9tNSFdlZhipFHvRKbwDMY+NzbsRPJzrTM dpqYsgx2dfc8RddotP+LSKOBdSU8wQSjPZIpFCQ457M+PmUDUxXGkaLh4pGfHx6Jqc3W5iZQNt H7aVYHnPk9bSyUGihvopqQQPR5QjkEzeJsRVkt+bfNVIWYTcf205XhBEN4sd2du2MqRDqNWn+u s8Y= X-SBRS: 2.7 X-MesageID: 9444048 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.69,249,1571716800"; d="scan'208";a="9444048" From: Sergey Dyasli To: Date: Wed, 27 Nov 2019 10:04:30 +0000 Message-ID: <20191127100430.9635-1-sergey.dyasli@citrix.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Subject: [Xen-devel] [PATCH v4 for 4.13] x86/microcode: refuse to load the same revision ucode 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: Juergen Gross , Sergey Dyasli , Andrew Cooper , Jan Beulich , Chao Gao , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Currently if a user tries to live-load the same or older ucode revision than CPU already has, he will get a single message in Xen log like: (XEN) 128 cores are to update their microcode No actual ucode loading will happen and this situation can be quite confusing. Fix this by starting ucode update only when the provided ucode revision is higher than the currently cached one (if any). This is based on the property that if microcode_cache exists, all CPUs in the system should have at least that ucode revision. Additionally, print a user friendly message if no matching or newer ucode can be found in the provided blob. This also requires ignoring -ENODATA in AMD-side code, otherwise the message given to the user is: (XEN) Parsing microcode blob error -61 Which actually means that a ucode blob was parsed fine, but no matching ucode was found. Signed-off-by: Sergey Dyasli Reviewed-by: Chao Gao Acked-by: Jan Beulich --- v3 --> v4: - added missing microcode_free_patch() v2 --> v3: - move ucode comparison to generic code - ignore -ENODATA in a different code section v1 --> v2: - compare provided ucode with the currently cached one CC: Jan Beulich CC: Andrew Cooper CC: Roger Pau MonnĂ© CC: Chao Gao CC: Juergen Gross --- xen/arch/x86/microcode.c | 20 ++++++++++++++++++++ xen/arch/x86/microcode_amd.c | 7 +++++++ 2 files changed, 27 insertions(+) diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c index 65d1f41e7c..6ced293d88 100644 --- a/xen/arch/x86/microcode.c +++ b/xen/arch/x86/microcode.c @@ -640,10 +640,30 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len) if ( !patch ) { + printk(XENLOG_WARNING "microcode: couldn't find any matching ucode in " + "the provided blob!\n"); ret = -ENOENT; goto put; } + /* + * If microcode_cache exists, all CPUs in the system should have at least + * that ucode revision. + */ + spin_lock(µcode_mutex); + if ( microcode_cache && + microcode_ops->compare_patch(patch, microcode_cache) != NEW_UCODE ) + { + spin_unlock(µcode_mutex); + printk(XENLOG_WARNING "microcode: couldn't find any newer revision " + "in the provided blob!\n"); + microcode_free_patch(patch); + ret = -ENOENT; + + goto put; + } + spin_unlock(µcode_mutex); + if ( microcode_ops->start_update ) { ret = microcode_ops->start_update(); diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c index 1e52f7f49a..00750f7bbb 100644 --- a/xen/arch/x86/microcode_amd.c +++ b/xen/arch/x86/microcode_amd.c @@ -502,6 +502,13 @@ static struct microcode_patch *cpu_request_microcode(const void *buf, if ( error ) { + /* + * -ENODATA here means that the blob was parsed fine but no matching + * ucode was found. Don't return it to the caller. + */ + if ( error == -ENODATA ) + error = 0; + xfree(mc_amd->equiv_cpu_table); xfree(mc_amd); goto out;