Received: by 10.223.185.116 with SMTP id b49csp6187077wrg; Wed, 28 Feb 2018 05:27:57 -0800 (PST) X-Google-Smtp-Source: AH8x22565yj49/IFWiJRexcxwfFW4tfUAai8DnOWxAyHSaLKPvjgCeL8cRjsl/8Wv6Vy+O4RJCTK X-Received: by 10.101.93.138 with SMTP id f10mr14012266pgt.255.1519824477044; Wed, 28 Feb 2018 05:27:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519824477; cv=none; d=google.com; s=arc-20160816; b=IguGMEy4uNAtDKfdXDzMYcW3ksTlsu7zknBmYk80lpczCQEEdXSJENWoooiQLi+xvP mB5SqauM+IWGoP/A3ZK6B9Xd4aheBTbFMIXV/+aP3OsD4mOyQjbAJonTREKZ+8+FflCw OD7Mr1YNeE6DI/UkpHM4agXHFGYnAtj1o1QtWidJw/+PPPG1RYUNi+emveV4Q+6DSx8R pAVG/6LtV0tkqntiV3JLOd9kjZCLi0h+wV4Xaq1cyvXh/4tCSXz9AtJvpYl9NLBNoi9x HOQwrq/kwDRNSL+eAAK17X+Y18ok6hTVS1zEpI5JSjMDsBR16qkedk8Vksc+Ath9xewx 2jfg== 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:arc-authentication-results; bh=ZeedpWhkUZHb0lXPxXyq1nXaZrS4fgHEnq3MiLfnQik=; b=Hcx/syzUWpunwXNaRXmvBk5yIsJtgAL5sxxyy9H5/qsjJ0qiSbmpTTZcE91Vi2lqzY BkuPT2RPnBwxMbrBxJRj8jPD2EssdBCea7240TjFeOIEgkfKCErjWmkXa7ZdNg9qGB6g B05Df8ALNRx6SjwrC+X9JS1ztrP0DbQCBClSG27oRMOP7oyeRFtkuU9Emt8Tho9Q/kmw EUknWQmodld40ocAqyHzQYbOBl3dBs5V/7dLncAJBMenTVX+gEkyLjqdlcvBqybaQhQy ksNLO4JMEpNlnsSbiCXC8wymdpZxtEJyrp2q7M9y+a/BX5qbnzhTNP0pbc2/aRNaBVq7 LmYg== ARC-Authentication-Results: i=1; mx.google.com; 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 u188si1243119pfb.220.2018.02.28.05.27.41; Wed, 28 Feb 2018 05:27:57 -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; 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 S1752754AbeB1N0n (ORCPT + 99 others); Wed, 28 Feb 2018 08:26:43 -0500 Received: from mga01.intel.com ([192.55.52.88]:23688 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752565AbeB1N0l (ORCPT ); Wed, 28 Feb 2018 08:26:41 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2018 05:26:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,405,1515484800"; d="scan'208";a="21428012" Received: from araj-mobl1.jf.intel.com ([10.255.66.201]) by orsmga008.jf.intel.com with ESMTP; 28 Feb 2018 05:26:40 -0800 Date: Wed, 28 Feb 2018 05:26:40 -0800 From: "Raj, Ashok" To: Henrique de Moraes Holschuh Cc: Borislav Petkov , X86 ML , Arjan Van De Ven , Tom Lendacky , LKML , Ashok Raj Subject: Re: [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline Message-ID: <20180228132639.GA23235@araj-mobl1.jf.intel.com> References: <20180228102846.13447-1-bp@alien8.de> <20180228102846.13447-5-bp@alien8.de> <20180228131156.i4y6la7besdflffd@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180228131156.i4y6la7besdflffd@khazad-dum.debian.net> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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.