Received: by 10.223.185.116 with SMTP id b49csp6170315wrg; Wed, 28 Feb 2018 05:13:19 -0800 (PST) X-Google-Smtp-Source: AH8x224iQg7vvGnCJO6JaUMPtUR6c2FMzjQ6aRHRZTQIU62VpJQU9/3dZMXYjRl1eqtMIskaiW3O X-Received: by 2002:a17:902:522:: with SMTP id 31-v6mr18015306plf.122.1519823598881; Wed, 28 Feb 2018 05:13:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519823598; cv=none; d=google.com; s=arc-20160816; b=b9dr1oQo+XRDgxK/hNlirUBAzpy0XF/+/tgEo+UFD4RURTwhAbcH/BTaSHgOpVNNG8 AAvuV22UCxYXVSX9jcwqadme3WVJYPQg7wfbdo6gaB6zWoWEWXnLwscV5UiyTPJZqxBM 6U4qwPMtjD+RcfnlifGQaDtuExEd906ijDz/E5A28mHTzuDpGeXE6dm/HgR0dQeat+zc 8cRQa2Hi8n5Apd0T6+zqVESrylYzB28JqTfOYfUvUVxJwEwlojR5y3zSrEuVQEJNi8rF nNOzeAn99jRzQItt/OKCk4hn3DjunUz3kcY6gm7gWw3Nu3SiVxgU/c5h9cC6UtVTdcjp 3mwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature :arc-authentication-results; bh=lluFvM6xLUH/PFqJJyji/Hc9u6GVziCl08aOIlljiXg=; b=dTe3xu7VY9Gg/qUQ+mdjrdrsGVeoO34GsTWqwMcCgly1Xl2Q+l9C3//MXVComAsfIr Vv/xzBjsLzgG+HL52FM2dUgopB9X8aaOttlkKK6pp533kQWuE8hkrf2Sq9vD9SR2+9Pg hJ+BlUngw//ut0EXfhLasPcoKZ5I+YAEgYRQqrzFKS35828pJSpAcn2dhwoHliHc6lB9 WSiaGiIv1OrH2nWGSudjQT+Jp0K418IH38LA9eaMBzyrYP2/SSXT075KGrw1bZnet95n mMedgsrGl0hVAIW6AxMYa0esUuVknNYD7Oq21/hIhqitaH9O9WBfSv/ncuaKvorJbah2 SwUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hmh.eng.br header.s=fm1 header.b=i/rqAlNA; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=PoOrsZDx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 127si1021066pgd.561.2018.02.28.05.13.03; Wed, 28 Feb 2018 05:13:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@hmh.eng.br header.s=fm1 header.b=i/rqAlNA; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=PoOrsZDx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752744AbeB1NMD (ORCPT + 99 others); Wed, 28 Feb 2018 08:12:03 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:40195 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752329AbeB1NMA (ORCPT ); Wed, 28 Feb 2018 08:12:00 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DDCA420ACE; Wed, 28 Feb 2018 08:11:59 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 28 Feb 2018 08:11:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hmh.eng.br; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=lluFvM6xLUH/PFqJJyji/Hc9u6GVziCl08aOIlljiXg=; b=i/rqAlNA WF3D31ed4qPkeZ9MaJ+Zsd8MyJ5KK06ePHVXKqQ8ejWiEwNlA0WXsRZZF4huEvxN K3iX0ZSby7CEz1l3jrxvZZzsWseO/cRUIPLf15WQYPXJUAR+0bUOPHjrzNYQS0e2 sGKi5GlAfkJ57JRA0vBjXXlSsWo/PD8b8RWTr8qHuQD9xP54tmTJ0UUGpl9MMIGK TPWh6wFfGcHwZ9lrTnRfchj2hwgTOfBiOjD56lM21izSNMI2WbWzeJDPJM/suPZ2 HdJQNns+wpLKzBQu905L1HRJySU8rCOYzUCM1HVl/jw1looHmQPPy6ebFL6gBsHU o6VuualIY0P6nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=lluFvM6xLUH/PFqJJyji/Hc9u6GVz iCl08aOIlljiXg=; b=PoOrsZDxoQpjk9MFyeaizfOAplJvS+B7bhrgFzPnJBI5D YI5u7MsikyM/oeGiCq+ihTUp5G9GtPBLHbsPOkKkROJmxN1fuyZP1m68ywrnhCrg peLg9lTdLmw4kzh+m55SudQrImSWZpCvRlM3YzTQ4745wn/0T6eK9S6lqQtXiTJc cBib7905DBh3il09OraDzbAT+n9WujNsBjgMLuJqf7hvTuRqbP/u1LoxHO4smHsV YDyMRwi9Je1J/DuIZszbmnveUpPQ3tFtfFqXbJqnlv3wvYN9k1RsxbAX54mI5oUA USo2AYQdvWtqG+lrCjZyhGM3PTmwAfe/1FVkMNSTA== X-ME-Sender: Received: from khazad-dum.debian.net (unknown [201.82.128.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 844A624802; Wed, 28 Feb 2018 08:11:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id 8C6ED3400411; Wed, 28 Feb 2018 10:11:57 -0300 (-03) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id j05yNbm2qbQC; Wed, 28 Feb 2018 10:11:57 -0300 (-03) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id 1CADA340040A; Wed, 28 Feb 2018 10:11:57 -0300 (-03) Date: Wed, 28 Feb 2018 10:11:56 -0300 From: Henrique de Moraes Holschuh To: Borislav Petkov Cc: X86 ML , Arjan Van De Ven , Ashok Raj , Tom Lendacky , LKML Subject: Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline Message-ID: <20180228131156.i4y6la7besdflffd@khazad-dum.debian.net> References: <20180228102846.13447-1-bp@alien8.de> <20180228102846.13447-5-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180228102846.13447-5-bp@alien8.de> X-GPG-Fingerprint1: 4096R/0x0BD9E81139CB4807: C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 28 Feb 2018, Borislav Petkov wrote: > Avoid loading microcode if any of the CPUs are offline, and issue a > warning. Having different microcode revisions on the system at any time > is outright dangerous. Even if we update that microcode during CPU early bring-up, before we mark it on-line and start using it? AFAIK, late-loading or not, this is what should happen in the current code: APs that are brought up after a microcode update is loaded (either by the early or late driver, it doesn't matter) will be always *early-updated* to the new microcode. Is it dangerous to have an offline core at an older microcode revision than the online cores? I am not against the patch, mind you, but I am curious about why it is supposed to be dangerous if we're updating the CPUs before we start using them *anyway*. Also, if this is really dangerous, does it means safe CPU hotplug isn't possible? AFAICT, the firmware would have to do it for us, but it *doesn't* have the up-to-date microcode (*we* had to update it)... -- Henrique Holschuh