Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp989216pxb; Fri, 15 Apr 2022 17:34:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPh6YfddZgYvdftzQmDTJXWlvXzAGhtkcZYjDTfaEUj4vYA6FgklSaPZ//kfwf9NflY2SM X-Received: by 2002:a63:368a:0:b0:398:2829:2698 with SMTP id d132-20020a63368a000000b0039828292698mr1175296pga.172.1650069248856; Fri, 15 Apr 2022 17:34:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650069248; cv=none; d=google.com; s=arc-20160816; b=Nypw3KdWKe6GekPwwUwuRP4PCDB/o50JnIzpZKor0lc6QjeAEmgCdSjBhCKvlcwb1p eKjGyD78O7m3gVhlb57f5+FvzXeE+CNItslyw2UmSJ9NavZ92qaHXyIX6cwbapn/tt1l WMFxPRqPGNV92lhcn0u2bbUannIUi90BISLql7zYKDxXDsXMzRuYNhkACgo+HbhariOY MIkiG00Dsag6Q+x0PTjQKK06hpFUsEzC5e03BKtIoBbmUFT029rZ0ME47O2YwH4Qawyz yMNY7lO4T4opJIFi3X6/34pywHqPRDUACkXuNPcWAZu8WbbGAxiI4Csm1r/+OhT+hMan fotQ== 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=IijIugVERxpnQFBsVmvUdJjEVqk+79yfC2GrePVHzLc=; b=mOmDqTMRsmLzjyvLsAe3GKqVOQLqS8DjU1Nq9icMik/f+7xuoa6FXgkOvjgHbZYsQ5 p/JhUk6wBXy9E10XKdfXylxt6EOOTrNnfyBuYhKJIVpDxIT5Nlz5vDaHGW1dWfDu/Exi 7sdt3teMXvZI7xAXN2XHOGCa84D8HsFEf8jpKyAJQnwFM87PGp6tGABOcKd+1gVKBH0W Tli/Bbx7+hxpoZvVcf5PQ5ipi98bDSwzj8a2fvF7gARelMWP24mbs+VgLs7hXM80rosK L0zlA6tBIF//BdKg54A2ueqjVrFrDSLlz1zTD0tsYBGbn8Q3JW7LHMB0XJirTEV/b+EX 2jRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c3Nmr33F; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id k15-20020a637b4f000000b003816043f05fsi3036946pgn.596.2022.04.15.17.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:34:08 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c3Nmr33F; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9CC0DE6C71; Fri, 15 Apr 2022 17:30:26 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355862AbiDOQkg (ORCPT + 99 others); Fri, 15 Apr 2022 12:40:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355858AbiDOQke (ORCPT ); Fri, 15 Apr 2022 12:40:34 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08691C681D; Fri, 15 Apr 2022 09:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650040685; x=1681576685; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XpehSo+Yn1FEBq+S4w2h8XLNT3XV05KHiZHdNjCxEY4=; b=c3Nmr33FdPxbk2KlvxU5eN50ApentVJYcf404rE0zFgcIhu/+jk1lAty eoQd9QnVNCXcmXAW2YeNrGtWbXUoalYm1Za9ha9Z4OevaMqBbQc35+Wcc zFbNXsHX9zS3Cre+HoaPLt8aJEp/D1kcH80N81eUnW4dCNhoHaJhdMR/f JUenNG3GkM42z333FrftWrq4GHTUcVku17lyk0oGb9+uHIFTiDoYSC184 9o0DVuIqO2qBxiVUj7uPfQBewz/tTSxm5MMpeo26RQjaVibr/8IxDBPIG yqRGfeTUkQKiFO7O0I5+GVXNgZmb7wnOGEXPUbdcw/JZiX78L4HD2aQkz Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10318"; a="243768343" X-IronPort-AV: E=Sophos;i="5.90,263,1643702400"; d="scan'208";a="243768343" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 09:38:05 -0700 X-IronPort-AV: E=Sophos;i="5.90,263,1643702400"; d="scan'208";a="646108786" Received: from agluck-desk3.sc.intel.com ([172.25.222.78]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 09:37:59 -0700 Date: Fri, 15 Apr 2022 09:37:57 -0700 From: "Luck, Tony" To: Yazen Ghannam Cc: bp@alien8.de, Smita Koralahalli , linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com, Dave Hansen Subject: Re: [PATCH v5 2/2] x86/mce: Add support for Extended Physical Address MCA changes Message-ID: References: <20220412154038.261750-1-Smita.KoralahalliChannabasappa@amd.com> <20220412154038.261750-3-Smita.KoralahalliChannabasappa@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Fri, Apr 15, 2022 at 02:56:54PM +0000, Yazen Ghannam wrote: > 3) OS, or optionally BIOS, polls MCA banks and logs any valid errors. > a) Since MCi_CTL, etc. are cleared due to reset, any errors detected are > from before the reset. On Intel not quite any error. H/w can still log to a bank but MCi_STATUS.EN bit will be zero. We've also had some BIOS code that did things that logged errors and then left them for the OS to find during boot. But this sequence does give more confidence that errors found in banks duing boot are "old". > I agree. The Intel SDM and AMD APM have the following procedure, in summary. > > 1) Set MCG_CTL > 2) Set MCi_CTL for all banks > 3) Read MCi_STATUS and log valid errors. > 4) Clear MCi_STATUS > 5) Set CR4.MCE Yes. That's what the pseudo-code in Intel SDM Example 15-1 says :-( > > I don't know of a reason why STATUS needs to be cleared after MCi_CTL is set. > The only thing I can think of is that enabling MCi_CTL may cause spurious info > logged in MCi_STATUS, and that needs to be cleared out. I'm asking AMD folks > about it. > > Of course, this contradicts the flow I outlined above, and also the flow given > in the AMD Processor Programming Reference (PPR). I wonder if the > architectural documents have gotten stale compared to current guidelines. I'm > asking about this too. I will ask architects about this sequence too. -Tony