Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp6099455pxb; Mon, 14 Feb 2022 15:29:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJwjKps1oRQAt96PzJlpCOgNEST+Ajr8vlNjE8LriMBwlgls5YtRDtqM9EYGK6YPnE1rJk7k X-Received: by 2002:a63:6ac1:: with SMTP id f184mr1198698pgc.524.1644881360785; Mon, 14 Feb 2022 15:29:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644881360; cv=none; d=google.com; s=arc-20160816; b=Ng6RkABGho4MvmQjtNS+V2bEmLgP8gNrtZZ96hgDyaZNumWoB4hMl6PXZhX3uD1PNb IIOaWDBUn12F4E00RGda+v2arWMrazH8RgBfz0quJ1qfG/X7RCozUSg5o/y0vcbSrWvh /XWfqGceFxSafDf4LT2Txt4qLRjdP0AFxzSavj9MbyNMLBfnMdoZBDmjSGm7psU7p+8u Y0t9F3J5nGpSp9Xwo4AKUuL23PCkHSkVPVcN5kgc+lEDrA7Tnu8U4Zg9JQ2hJLEcZBt7 g/BLkyVMYZqMNivOmHORLQ/iVr05BSK6dh4O/kclFY5OQrKJxojm1lhDmrsut7wXH/0M 8kQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Cs5V2GEmHEkZwjCgImn1CbcLXzgXzA2/Si46Uhdx/p4=; b=i7O+t/lfIuAa2grVvW4UhL7qKBKv0qGjGKHruRdfqHgYveHhh63szoHPDNyF2UTUqa X/OWzhTW0RQ07Utlibs0J4AV7ZiSZmLI9j7aeCEEQxO2goD79Iutl5oQPO08V5z+lubF 39IzhqcWbro9fisVsAoiIRzUgOJfhDOOxNL6odSGRGjOlG++xx6ni+LUioAAk9L+EGdD ocI7hre1W3vqrmp45sXKAh0nShVjvyazuhY9aYq3F3eVt/lc+r5z0gGaAvL9NP6x8hce VnGD2eG14tR8WtCsi4OOdcLOi0YgVQUpNvMR9wg00+GQ6aOLFrpDsasy8Qv9qJm7MGY3 /voQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="M/bQXUrn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g64si1036279pgc.64.2022.02.14.15.29.04; Mon, 14 Feb 2022 15:29:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="M/bQXUrn"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231949AbiBNWle (ORCPT + 99 others); Mon, 14 Feb 2022 17:41:34 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231579AbiBNWlc (ORCPT ); Mon, 14 Feb 2022 17:41:32 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34F667A994; Mon, 14 Feb 2022 14:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644878484; x=1676414484; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=5Eef639z1xq1nQFQJLCBg8R/waHFd3R5JFPWOOIPMLo=; b=M/bQXUrnEfWHI91W6PbS5ByqapJydUCf1nMLMogAcxHBT1X2hYm6gUnb BeHTbFdi/OXuqob++AWMI+jatvU9dvuLkhbsGoJC6qC8BEcTc92jPbqOE eb1xcEbfHlfSClTs/DZAEpLClICJ9pKhXrCS5GPMNY/7yY9DUeytQ+JBJ 9zdj3bDjGmUtouiYFPQwBSkH8so/QJq40809LY9mBwW3/Lk5Lc529oDfZ EqS8NvJG5xuIUj4Kgja20tuDVbCjMScVQRUG92RuyFEckgWb2g5uzA/EB Md3VWUyXy61OD369TsvRKKXLSRRLLN1jcv6FfQl3TNrPkEW1z9LGHhhhM w==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="247793088" X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="247793088" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 14:41:24 -0800 X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="632387331" Received: from guptapa-mobl1.amr.corp.intel.com ([10.212.244.212]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 14:41:23 -0800 Date: Mon, 14 Feb 2022 14:41:21 -0800 From: Pawan Gupta To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andi Kleen , Tony Luck , linux-kernel@vger.kernel.org, antonio.gomez.iglesias@linux.intel.com, neelima.krishnan@intel.com, stable@vger.kernel.org Subject: Re: [PATCH] x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits Message-ID: <20220214224121.ilhu23cfjdyhvahk@guptapa-mobl1.amr.corp.intel.com> References: <5bd785a1d6ea0b572250add0c6617b4504bc24d1.1644440311.git.pawan.kumar.gupta@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.02.2022 18:38, Borislav Petkov wrote: >On Wed, Feb 09, 2022 at 01:04:36PM -0800, Pawan Gupta wrote: >> tsx_clear_cpuid() uses MSR_TSX_FORCE_ABORT to clear CPUID.RTM and >> CPUID.HLE. Not all CPUs support MSR_TSX_FORCE_ABORT, alternatively use >> MSR_IA32_TSX_CTRL when supported. >> >> Fixes: 293649307ef9 ("x86/tsx: Clear CPUID bits when TSX always force aborts") >> Reported-by: kernel test robot >> Tested-by: Neelima Krishnan >> Signed-off-by: Pawan Gupta > ><--- I'm assuming this needs to be > >Cc: > >? Yes, this needs to be backported to a few kernels that have the commit 293649307ef9 ("x86/tsx: Clear CPUID bits when TSX always force aborts"). Once this is reviewed, I will send a separate email to stable@ with the list of stable kernels. >> @@ -106,13 +110,11 @@ void __init tsx_init(void) >> int ret; >> >> /* >> - * Hardware will always abort a TSX transaction if both CPUID bits >> - * RTM_ALWAYS_ABORT and TSX_FORCE_ABORT are set. In this case, it is >> - * better not to enumerate CPUID.RTM and CPUID.HLE bits. Clear them >> - * here. >> + * Hardware will always abort a TSX transaction when CPUID >> + * RTM_ALWAYS_ABORT is set. In this case, it is better not to enumerate >> + * CPUID.RTM and CPUID.HLE bits. Clear them here. >> */ >> - if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT) && >> - boot_cpu_has(X86_FEATURE_TSX_FORCE_ABORT)) { >> + if (boot_cpu_has(X86_FEATURE_RTM_ALWAYS_ABORT)) { > >So you test here X86_FEATURE_RTM_ALWAYS_ABORT and tsx_clear_cpuid() >tests it again. Simplify I guess. X86_FEATURE_RTM_ALWAYS_ABORT is the precondition for MSR_TFA_TSX_CPUID_CLEAR bit to exist. For current callers of tsx_clear_cpuid() this condition is met, and test for X86_FEATURE_RTM_ALWAYS_ABORT can be removed. But, all the future callers must also have this check, otherwise the MSR write will fault. >> tsx_ctrl_state = TSX_CTRL_RTM_ALWAYS_ABORT; >> tsx_clear_cpuid(); >> setup_clear_cpu_cap(X86_FEATURE_RTM); > >Also, here you clear X86_FEATURE_RTM and X86_FEATURE_HLE but the other >caller of tsx_clear_cpuid() - init_intel() - doesn't clear those bits. >Why? Calling setup_clear_cpu_cap() by boot CPU is sufficient to clear these bits for secondary CPUs. Moreover, init_intel() is also called during cpu hotplug, clearing cached CPUID bits will not be safe after boot. >IOW, can we concentrate the whole tsx_clear_cpuid() logic inside it and >have callers only call it unconditionally. Then the decision whether >to disable TSX and clear bits will happen all solely in that function >instead of being spread around the boot code and being inconsistent. There are certain cases where this will leave the system in an inconsistent state, for example smt toggle after a late microcode update that adds CPUID.RTM_ALWAYS_ABORT=1. During an smt toggle, if we unconditionally clear CPUID.RTM and CPUID.HLE in init_intel(), half of the CPUs will report TSX feature and other half will not. Thanks, Pawan