Received: by 10.192.165.156 with SMTP id m28csp1479975imm; Wed, 18 Apr 2018 10:15:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+5bkEASClZz/wGSJwu7lhf90GOXJeuD+DbFhol6Z5F0gL2z5v1A9PX2zH9iUZLOkiIYXrY X-Received: by 10.98.30.4 with SMTP id e4mr2752066pfe.212.1524071733068; Wed, 18 Apr 2018 10:15:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524071733; cv=none; d=google.com; s=arc-20160816; b=tdO+sJMJI0SLt6cgRR3IjjtoA4Cxxvqt1od47ioiVFYXdQdW/ny8EFNbnPjQO/o2QH 1sJN00xQN6hsCeQcTokTxel8LniSy9xgWsqxQglVlUwVLkTUm9jKELHFQ8srrZeoOWAh 3kRzRHZClaHyhr+pKquSegvVIJuv5eCFygox7y2mgM2fPdCbDrRFssDuqcrx2lQoYcOy qsOp3ps+zd1sFZZtzCBp182XcjDYiKUrNKZ8HQUdz8CPx/RLOG1kg+fxWZUf7+1Z1hvu +tmXjhuzl6fXmEwtT38KllE8SFnQ63+OF+Vx+mCpC1IRMTJ82dIsDedenyxjHHAQ+Xot mUJQ== 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:arc-authentication-results; bh=fd3CmlQ7BLUyg+4OjnWh8RMXU6c4sKQ0KS6Vy9ZDkrA=; b=NKUETLAt/Uypv5eF1LhCCKI1wsiY6st49C76ftUqCoGMrx8geq0jQl+Jbgkq3GT/gO 5CazIzdjr0ZztRbpgE+yhqnaNDrqor2OxJjstzt0iE2ZfPsoGOPR5YVzE9uvKqQCAvqZ Yy9Ut4gT5GfJyO2BhjV91EAWaSri4wwpEBttI6cjsU3Lnqr/IcxfxfYMW2cyDVvg8nIr gYx+90LtdOWK1gGOJzGNNA8E3m8mDTagNAVPUsmk9UxKw4qMZggLQSl8z3ZttyonsOPi pRyYtRYUOpplbWD1rfMaEEUhvZprXXnBPCPPRJWNbsqs5nLir5r6m+gMZbFHOqUG00oO 6FXA== 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 u7si1464346pgc.141.2018.04.18.10.15.18; Wed, 18 Apr 2018 10:15:33 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752810AbeDRROJ (ORCPT + 99 others); Wed, 18 Apr 2018 13:14:09 -0400 Received: from mail.skyhub.de ([5.9.137.197]:50114 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752077AbeDRROI (ORCPT ); Wed, 18 Apr 2018 13:14:08 -0400 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BQmiMAQMHv4Y; Wed, 18 Apr 2018 19:13:50 +0200 (CEST) Received: from pd.tnic (p200300EC2BCA86003047E01E637F8411.dip0.t-ipconnect.de [IPv6:2003:ec:2bca:8600:3047:e01e:637f:8411]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7D9131EC00E5; Wed, 18 Apr 2018 19:13:50 +0200 (CEST) Date: Wed, 18 Apr 2018 19:13:47 +0200 From: Borislav Petkov To: "Ghannam, Yazen" Cc: "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "x86@kernel.org" Subject: Re: [PATCH] x86/MCE, EDAC/mce_amd: Save all aux registers on SMCA systems Message-ID: <20180418171347.GH4795@pd.tnic> References: <20180402195707.42875-1-Yazen.Ghannam@amd.com> <20180417172102.GA3633@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 Tue, Apr 17, 2018 at 06:30:34PM +0000, Ghannam, Yazen wrote: > We could but it's an issue of documentation and testing the older systems. > > My first pass at this was to unconditionally read the registers because my > understanding was that registers that aren't accessible would be read-as-zero. > I thought this was a common MCA implementation. But Tony pointed out that > this isn't the case on Intel systems. This is the case on recent AMD systems. But > I don't know if it's the case on older systems which may or may not have > followed the Intel implementation more closely. So if our worry is the #GPs, we can always use the rdmsr*_safe() variants and look at the return value. And dump a invalid value like 0xdeadbeef or so, if the read failed. But if any bit of info we've gotten this way, helps us debug an MCE, we're already golden! > For example, > > Deferred error occurs: > - MCA_{STATUS,ADDR,DESTAT,DEADDR} all have valid data. > > MCE occurs > - MCA_{STATUS,ADDR} are overwritten with non-zero data. > - MCE handler clears MCA_STATUS. MCA_ADDR is non-zero. > > DFR handler finds MCA_STATUS[Deferred] is clear, so it saves > MCA_DESTAT and MCA_DEADDR which is 0. > > If !m->addr (which has MCA_DEADDR), then we read MCA_STATUS > which has the address from the MCE. The code could use a shorter version of this as a comment to state why we're doing it. Because it is not obvious. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.