Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1136302yba; Thu, 16 May 2019 15:09:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwubC9ZPuhXNRYMgV3f/tVByFWdlb8TfnWgkz3ruZDYvE6ngwT8nKyGR2wR3Rj9jSLVX+Fr X-Received: by 2002:a63:2c4c:: with SMTP id s73mr52616900pgs.42.1558044570176; Thu, 16 May 2019 15:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558044570; cv=none; d=google.com; s=arc-20160816; b=e/loX4uQBZHHZHMYeA2AntQaJS5tOJ8mnh0cNMmqRwr0XlqI38YFT68obvTjiZTMZG OsORMcify8zXX5x65AIgXmcfDtvNJHAGx9K3g5WAYhMjJb/7avMn5xWZCHykCoM9vIOy hPsrzRZADKf6xWy8ch5iafdFZlO5vvwBlmr0k2ndELjkfhjl718vG9pHZLlRbxNDNzWD NuExUjc/+jNeKEeUNX/smSbkVWE/9kDOHDLV5R+ALO2xgQwfYGeVOFz8iAQIuMEp93Oe Lwk24E9vshQ48HUI00vUnoFSYQizzTHTHGEQcO0qgT9BKR+vXb8xG8wIu98rj2Mn44mV x+0Q== 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; bh=1hyLgiqr3xUJv3RJLPLlPPWQ7gLde+hdl+66JI8S9WU=; b=gZoL2MpqDPuj4k7npjf3Y1mlMEeEmjQtBs0+mFoo/WKyerBSmDaxcrWV0MBDoQKYbZ 2i2yvPTl1WA5Gbe5jgmAGmLr8Zrn1IksmLWMGvtCuDR4cSYsuSWKS/CtaR9G/VVoUfBT UAtP+gwvXvaOZVHmig+0U8RqrEl48vMviflytu6RzM9X7WZffDHlrFHB4OaZF5flXxcS DPymSO/W+PI8qFgkvjw4c76aMOhPyfq/5BGDeI39y13DeWA3LsohD9W5BeyaBFmB24Gk d3lEyl68cEINY25Z4FPYIdPE4wwo+vR/YY3OgWnlOdxcU9qUe5QKLY7CKxdiG/YUu7uS nakQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2si6448765pln.360.2019.05.16.15.09.13; Thu, 16 May 2019 15:09:30 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728179AbfEPU7q (ORCPT + 99 others); Thu, 16 May 2019 16:59:46 -0400 Received: from mga17.intel.com ([192.55.52.151]:5975 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727951AbfEPU7o (ORCPT ); Thu, 16 May 2019 16:59:44 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2019 13:59:43 -0700 X-ExtLoop1: 1 Received: from agluck-desk.sc.intel.com (HELO agluck-desk) ([10.3.52.160]) by fmsmga007.fm.intel.com with ESMTP; 16 May 2019 13:59:43 -0700 Date: Thu, 16 May 2019 13:59:43 -0700 From: "Luck, Tony" To: Borislav Petkov Cc: "Ghannam, Yazen" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "x86@kernel.org" Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that get set in hardware Message-ID: <20190516205943.GA3299@agluck-desk> References: <20190430203206.104163-1-Yazen.Ghannam@amd.com> <20190430203206.104163-6-Yazen.Ghannam@amd.com> <20190516155202.GA11517@agluck-desk> <20190516165648.GB21857@zn.tnic> <20190516172117.GC21857@zn.tnic> <20190516203456.GD21857@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190516203456.GD21857@zn.tnic> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 10:34:56PM +0200, Borislav Petkov wrote: > On Thu, May 16, 2019 at 08:20:58PM +0000, Ghannam, Yazen wrote: > > We don't actually know if there are bits set in hardware until we read > > it back. So I don't think this is adding anything new. > > Bah, of course. We need to read it first (pasting the whole function). > Now, __mcheck_cpu_init_clear_banks() gets called when we change > configuration too, in mce_cpu_restart() and if we do it this way, we'll > be rereading MCi_CTL each time but I don't see anything wrong with that. Intel doesn't "set any bits in hardware" ... so I think you'll just get a 0x0 and disable everything. > > Hmmm? > > static void __mcheck_cpu_init_clear_banks(void) > { > struct mce_bank *mce_banks = this_cpu_read(mce_banks_array); > int i; > > for (i = 0; i < this_cpu_read(mce_num_banks); i++) { > struct mce_bank *b = &mce_banks[i]; > > rdmsrl(msr_ops.ctl(i), b->ctl); > > /* Bank is initialized if bits are set in hardware. */ > b->init = !!b->ctl; > if (b->init) { > wrmsrl(msr_ops.ctl(i), b->ctl); > wrmsrl(msr_ops.status(i), 0); > } > > } > } I think the intent of the original patch was to find out which bits are "implemented in hardware". I.e. throw all 1's at the register and see if any of them stick. I don't object to the idea behind the patch. But if you want to do this you just should not modify b->ctl. So something like: static void __mcheck_cpu_init_clear_banks(void) { struct mce_bank *mce_banks = this_cpu_read(mce_banks_array); u64 tmp; int i; for (i = 0; i < this_cpu_read(mce_num_banks); i++) { struct mce_bank *b = &mce_banks[i]; if (b->init) { wrmsrl(msr_ops.ctl(i), b->ctl); wrmsrl(msr_ops.status(i), 0); rdmsrl(msr_ops.ctl(i), tmp); /* Check if any bits implemented in h/w */ b->init = !!tmp; } } } -Tony -Tony