From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0B0CC352A1 for ; Wed, 6 Apr 2022 02:02:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1845940AbiDFCCD (ORCPT ); Tue, 5 Apr 2022 22:02:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1457461AbiDEQDP (ORCPT ); Tue, 5 Apr 2022 12:03:15 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B7A7A6E2A for ; Tue, 5 Apr 2022 08:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649173639; x=1680709639; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=A+rkSrQ9YlVDO5qD3GUl3Wuak+sW+zKmsgvd5IM6ge8=; b=NYB3pXXTDZK/WpSPr6wEqyRaJrN+RExEawEAxS50vvT3g9++v++SCfb4 RSh+WZtL1oL1yCqkMV6aDPNd+QKvrbkxWsDUl378stQbFgBCCwWMgj0Jp CBtwtF6k0y2I8G68WbtfvGRZLg0d1Ta4qODgYMrbdfCEmJgUQ7tgVNnEV C4yQ8Pd3ETB5PqRnv2fzkZXqRD6zCf4EywhAJCUUoJTO/+ROWBfHlRfLY D+ohX+B+Mbi/PBUbjcLOIeuwnJECxCDUF6UgyDBCcLg1lQfzhKKA4NXJn 2G0ygZEKtjds1Hd9G1cJ3lKrL+X4qvQKBxkfhOb1chlpP9MnM5kyDBZNg A==; X-IronPort-AV: E=McAfee;i="6200,9189,10308"; a="240718958" X-IronPort-AV: E=Sophos;i="5.90,236,1643702400"; d="scan'208";a="240718958" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 08:47:18 -0700 X-IronPort-AV: E=Sophos;i="5.90,236,1643702400"; d="scan'208";a="549107626" Received: from nldesimo-desk1.amr.corp.intel.com (HELO [10.212.148.3]) ([10.212.148.3]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 08:47:17 -0700 Message-ID: <5873a444-bb32-f0d5-27f1-173f469baf21@intel.com> Date: Tue, 5 Apr 2022 08:47:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "Limonciello, Mario" , Peter Zijlstra , "Karny, Wyes" Cc: "linux-kernel@vger.kernel.org" , "Carroll, Lewis" , "Shenoy, Gautham Ranjal" , "Narayan, Ananth" , "Rao, Bharata Bhasker" , "len.brown@intel.com" , "x86@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "hpa@zytor.com" , "chang.seok.bae@intel.com" , "keescook@chromium.org" , "metze@samba.org" , "zhengqi.arch@bytedance.com" , "mark.rutland@arm.com" References: <20220405130021.557880-1-wyes.karny@amd.com> <7cdc2103-c6d4-e1b6-9804-6739112eee4d@intel.com> From: Dave Hansen Subject: Re: [PATCH] x86: Prefer MWAIT over HALT on AMD processors In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/5/22 08:34, Limonciello, Mario wrote: >>> if (!static_cpu_has(X86_FEATURE_ZEN)) { >>> msr |= ssbd_tif_to_amd_ls_cfg(tifn); >>> wrmsrl(MSR_AMD64_LS_CFG, msr); >>> return; >>> } >> This seem _bit_ at odds with the commit message (and the AMD SSBD >> whitepaper): >> >>> Add the necessary synchronization logic for AMD family 17H. >> So, is X86_FEATURE_ZEN for family==0x17, or family>=0x17? > There are Zen family CPUs and APUs from family 0x19. Perhaps at the > time of the whitepaper there weren't yet though. Is this a gap in the documentation, then? Is there some documentation of the availability of SSBD mitigations on family 0x19? Anyway, back to MWAIT... It would be really great to include the assumptions about what X86_FEATURE_ZEN means in the context of this patch. Does this patch *really* mean "Zen microarchitecture" only?