Received: by 10.223.185.116 with SMTP id b49csp6540438wrg; Wed, 28 Feb 2018 11:09:58 -0800 (PST) X-Google-Smtp-Source: AG47ELu7BfqdAn4kqQpsLzNXNB73zWBWLxjumcmH3t6ZetT/fuK6d+bIXTiohKgTMYcIalFAjGJu X-Received: by 10.98.178.17 with SMTP id x17mr9461137pfe.2.1519844998153; Wed, 28 Feb 2018 11:09:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519844998; cv=none; d=google.com; s=arc-20160816; b=sf2ckZq/tfeYxR6M5L4Iui0zAydX519gZA7oj6YEad+DBx1dWhwRBv4qA0Ouqe4C0v 8y0C2keSIx5yR0nBT4zRA7uVY8vxGBGF8mFkreSWQbpE8LUPIpdwB/eTnhRYKr7XtEGO EJHxhewS+QB0d1tG675ZzhsqgWB5/zjwCkGmj7+5RZhVlus9A28jeEwNcHy7DCkNUTbE BbxcRCuF3m6uF+mYlZcZ491GdrU/5rBXdEjminUJP+M8/5vp23i/bMqclw7lSk7V5qpx UN0G8xrrzf1QaPZoutTsYvWhib5/sxFmnS8ZthYl8gICvvaNl1hIOxl1CQfJ2f8Q1hct n14A== 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=FgsNmK4YEA1oiMW+cjo/ZwfVIUiCoy/hjIXYJpuKnpk=; b=xAgK4NSxC8cxM+vLX7PMhGLWFUQhdaIUYoXSdyO0RRp0aRut56NDVjo9KjfRibjqEg aT8PQfAIoRKg550TqWZqjpzYQjylscEIrOWa3/vh3Ycw5kjDx6tQHYjTHdcsoDrDsRB8 M/MtzA0bjYNaMczsBBsdp4/s8YTWnWQiYmxIZthohvfxfIQEHVXxzAZac+SgTZjds/DZ 2lGS6fNZsiKM/LGLPlCsWDZaTHaCXUze8YIYfjEA9rV1ZpTaAo7Tei80jDvcWVH9LxVe GNIccgs0Rj7xerq2lJZn+1XftAU2x4BsEuWvj6CJlzsPBWq+nIT7AQfcsUcCVCZ6oROT djrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hmh.eng.br header.s=fm1 header.b=PSURPI8J; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=nI8l+IYo; 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 p1si1317653pgc.593.2018.02.28.11.09.42; Wed, 28 Feb 2018 11:09:58 -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=PSURPI8J; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=nI8l+IYo; 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 S933109AbeB1THa (ORCPT + 99 others); Wed, 28 Feb 2018 14:07:30 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57257 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932423AbeB1TH3 (ORCPT ); Wed, 28 Feb 2018 14:07:29 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 93C3620F32; Wed, 28 Feb 2018 14:07:28 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 28 Feb 2018 14:07:28 -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=FgsNmK4YEA1oiMW+cjo/ZwfVIUiCoy/hjIXYJpuKnpk=; b=PSURPI8J OfGazegTGdaMvEEfjigIngp8REGwWIOw7jnbyk3rE2I3KmRTwNtDZU0YP38Fm8qg mxaJjoLianVJxfkRIGcwL1D1vgTDtTnmPCJ1lKhRO4nTwMKmjF93XWpLSLR9W4CW QDj5XN7du06JwHgf8bj4Gm+w6/UC1htqAWBMPFwlPPHhRsYFcH4zEx6CFFacvAfv lGHhLqQ+BuWn+TC6H6eLJka9lax8nEd18XuPtDhnmKGMavKo4tsLULekoZK0ZqP9 BRRa2CS3GR9b4qy8DAYHMr9rZcWRVLwp8ut0YGz6xgd9jmo8JtxRk73pTyscMLFR ZtyTqW23OAAAlA== 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=FgsNmK4YEA1oiMW+cjo/ZwfVIUiCo y/hjIXYJpuKnpk=; b=nI8l+IYoIeeHEoLVRAuvHlqJBSm95g9IXhc6I+6uQIWOQ I7kjUct2XR4aRt+pvqK9R/rKqEJCcUYN1ivnj2HM24H8+qfIiyTXcz32xTbsnRRn Ul0JbOZkB4d4hHiaVPMBQiHuzex2d9e2cTVoI85LEmbzys1DIjgmvcYiYr0L8I3Y nKHOlV9JCzcmduWMYhyE0LRK+PUHtLw6j/YCGvAc+Bc9t/PYxaLHo8NMJm1MtNcT epR2J7UuDOcXSqYVn7Ax2KfeenZmLDHtaoCQMH8zV0MzpfAu3cxB4BE3DChf9juV XPNs70xxn/6lPLaH1njLcc4jRlW8JyyxOQUGvguuQ== X-ME-Sender: Received: from khazad-dum.debian.net (unknown [201.82.128.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 27A847E141; Wed, 28 Feb 2018 14:07:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id 6990B340040A; Wed, 28 Feb 2018 16:07:26 -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 J3vvWOSoakzI; Wed, 28 Feb 2018 16:07:25 -0300 (-03) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id 75FF13400404; Wed, 28 Feb 2018 16:07:25 -0300 (-03) Date: Wed, 28 Feb 2018 16:07:25 -0300 From: Henrique de Moraes Holschuh To: "Raj, Ashok" Cc: Borislav Petkov , X86 ML , Arjan Van De Ven , Tom Lendacky , LKML Subject: Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline Message-ID: <20180228190725.c2yuivmmfiezsict@khazad-dum.debian.net> References: <20180228102846.13447-1-bp@alien8.de> <20180228102846.13447-5-bp@alien8.de> <20180228131156.i4y6la7besdflffd@khazad-dum.debian.net> <20180228132639.GA23235@araj-mobl1.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180228132639.GA23235@araj-mobl1.jf.intel.com> 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, Raj, Ashok wrote: > On Wed, Feb 28, 2018 at 10:11:56AM -0300, Henrique de Moraes Holschuh 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? > > We don't want to leave a system and allow the user to update microcode > when some cpus are offline. Remember cpu_offline in linux is only > logical offlining.. so the cpu is still in the system.. it can even > participate in MCE for e.g. It is very much alive. Its not a question > that "Would it not work" but its not worth to leave an open door and > being paranoid is best! I see. Thanks for the explanation! > > 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)... > > The difference is hot-adding you know you are going to update the current > microcode. But leaving a cpu in offline state is leaving it stale for a long > time without realizing that you have some stale cores. That begs the question: do we have any reasons to not update the microcode even the offline cores? -- Henrique Holschuh