Received: by 10.223.185.116 with SMTP id b49csp1850413wrg; Thu, 22 Feb 2018 04:16:52 -0800 (PST) X-Google-Smtp-Source: AH8x225wJq4laqxafGjM1dmF3QneVLLGiV1JAVuzs0MXZn9QA0oFq6FhhE4YWGiTHESIkiRsrs+I X-Received: by 10.98.150.212 with SMTP id s81mr3594068pfk.100.1519301812104; Thu, 22 Feb 2018 04:16:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519301812; cv=none; d=google.com; s=arc-20160816; b=nj6wxNI8CeHrs8aRPissJBHPzO3+nTbmyJpKAOTPq2DjtOAztKRO/xxIHL+G40C+W1 s4NDBiDKMFXm89eQq4CE2H1Snm0JNL+FYCXP8F8WtxPHCM3Bf3WscqKEVi9+ON9VTtnX Oz/+ZIkyRT5HVzAsgVqwX2pu4MT3DZxIVwvFPyFp1OrTtu4Z+BS8GWVmo4/YD9aN7cfX zGtaX0NqUca7r3PLR96T13pAVjJBQcMNFMLxecAEHfby9cB4rwglbaGhffwmlS2VvUNo 5K8lMySRI5avTkULXoMeCV/xI62cdKW9uPXmGt5M3ZJdtmqN6Vn4P/l+oX1GQvWmFgmA 3iBQ== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=bP8ZeuZ7PjvooLj8SF4VK8HGKDhtWuGVaQOemdklUVo=; b=SnRGcURFdhNDPE1jvFfAswppXp6Vi44nSWWCf3GJrawJRuL0PA2FOJcsYFAQ3TOAgq iIYXQG8MdvRWXl39KtnDVyJimndohePGeCA7suaOFVxtZatkYeGg2+CHwlW4JnUtXCXx Eq5ON0oLij8rxN70ECYRs7sU7K7ZrketuvOBpJKFoEyHIrS/xXfeirSoIZT+CTze/jEn KtDGrTG4IgMiu4NZf4M4400iciwILtNWG7EkZMj1H3t75kGuOfl7VeoOM+YpDxTyTbbs ovT0jFGvv4YyV2oA44gsGh0HonNE4FAJFOJrXNko8KLF0IYrmciCYBftXxswD0P7uDTv LO/w== 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 t5si2533795pgf.93.2018.02.22.04.16.37; Thu, 22 Feb 2018 04:16:52 -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 S1753778AbeBVMP0 (ORCPT + 99 others); Thu, 22 Feb 2018 07:15:26 -0500 Received: from mx2.suse.de ([195.135.220.15]:42253 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753640AbeBVMPZ (ORCPT ); Thu, 22 Feb 2018 07:15:25 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8F901AEB5; Thu, 22 Feb 2018 12:15:22 +0000 (UTC) Date: Thu, 22 Feb 2018 13:15:06 +0100 From: Borislav Petkov To: "Raj, Ashok" Cc: X86 ML , LKML , Thomas Gleixner , Ingo Molnar , Tony Luck , Andi Kleen , Tom Lendacky , Arjan Van De Ven Subject: Re: [v2 1/3] x86/microcode/intel: Check microcode revision before updating sibling threads Message-ID: <20180222121506.GC27489@pd.tnic> References: <1519281205-58951-1-git-send-email-ashok.raj@intel.com> <1519281205-58951-2-git-send-email-ashok.raj@intel.com> <20180222110056.GA27489@pd.tnic> <20180222115554.GA3797@araj-mobl1.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180222115554.GA3797@araj-mobl1.jf.intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 22, 2018 at 03:55:54AM -0800, Raj, Ashok wrote: > The current code wasn't trying to enforce checking the loaded microcode revision on a thread > before attempting to load the microcode. While you comeback from resume, if C0T0 already > is up, and we loaded the early microcode, then when handling C0T1 there is no need to > do a wrmsrl to reapply microcode since its already loaded as part of C0T0. And I'm asking exactly this: is it simply "we don't need to do WRMSR" or "we should not"? Because avoiding the WRMSR costs more than simply doing it and letting the HT thread ignore the supplied microcode. If it is "we don't need to but there's nothing wrong when we do it" then we don't need this patch. And I'm pretty sure "nothing wrong when we do it" would be the answer. Otherwise we have bigger problems. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --