Received: by 10.223.185.116 with SMTP id b49csp5011196wrg; Tue, 27 Feb 2018 06:28:16 -0800 (PST) X-Google-Smtp-Source: AH8x227BJsgLbwU6fzl5sjZ+/tykuy6uE3rCtd68L3BUL8z3bkcxcNodZkf25zBjiDpBpQMRSZAh X-Received: by 2002:a17:902:5ac1:: with SMTP id g1-v6mr13969113plm.255.1519741696846; Tue, 27 Feb 2018 06:28:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519741696; cv=none; d=google.com; s=arc-20160816; b=te1Myp8TdTYeTfyzZMGwDKwGnfLAnFxfAE5wRZZL9ADe8dg5zGRV1TtmQJ31QePusv WXnnZE1QC6hZcqpxNkgZmR2oFgNgewsvwPqbIipWXlL3pcqGzSEe+eOKhMIBkhS6z6Lq FsJ7etbMF3cR1GDmBNyktDn+LSm7mdUJTv6I7qXRpI3qnvTVcdncnQcfUr4tfvCmd2T1 uRIyawbysD9SVL2FNy/O5MfwJrxd1NlepCdeCvbK7xhbGsAUG74E+Q3MnLhJupo0+PF+ omMjFd84VuygpB8v2NC2Fr4aQJmZpHPS4YOb/33t0MgNu8fBSZe5sTobGwEMoJ45hniy /flw== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=eoRWijBivpjkAiVLniJ2rRSwqJ7Z6v4ANsyInTyPF5k=; b=WMFLLPK4b9ZgpS+SPj72yeSgCqcI70pEicLRlJ4P7o0gAMuRLr9vj9zXKIuvlKYxe+ lILLgmDvFiX6V9e+9s/BaBDF8FDKcWxFhZKo+SVkV25FftbZoIDfGLlB+e2hMnfIC+Vh SxgV40y+EeOdNQSCWEPklMlQDdR+wDW5iTKfXyU7fW3rs+3KwNy5ocURc+Ejl/JgrBwM 5fkWzoHah2vR/JFsg5hyKp7HsL32864OWIEZLgG8qgc8f6MTxaGJw/w443R5RhLxxsBc IK5JsW+2AvWNKKMtsQakdfI5j9EZMNezuDr5cuhj3Lv7by2zj8N0KQk+dVAISFWh/a48 6oUA== 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 m7-v6si8931063pln.711.2018.02.27.06.28.01; Tue, 27 Feb 2018 06:28:16 -0800 (PST) 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 S1753360AbeB0OZ5 (ORCPT + 99 others); Tue, 27 Feb 2018 09:25:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:33021 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753117AbeB0OZ4 (ORCPT ); Tue, 27 Feb 2018 09:25:56 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BE002AD48; Tue, 27 Feb 2018 14:25:54 +0000 (UTC) Date: Tue, 27 Feb 2018 15:25:31 +0100 From: Borislav Petkov To: Yazen Ghannam Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, ard.biesheuvel@linaro.org, x86@kernel.org Subject: Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure Message-ID: <20180227142531.GF26382@pd.tnic> References: <20180226193904.20532-1-Yazen.Ghannam@amd.com> <20180226193904.20532-4-Yazen.Ghannam@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180226193904.20532-4-Yazen.Ghannam@amd.com> 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 Mon, Feb 26, 2018 at 01:38:59PM -0600, Yazen Ghannam wrote: > From: Yazen Ghannam > > Print the fields in the IA32/X64 Processor Error Info Structure. > > Based on UEFI 2.7 Table 256. IA32/X64 Processor Error Information > Structure. > > Signed-off-by: Yazen Ghannam > --- > Link: > https://lkml.kernel.org/r/20180223200333.6410-4-Yazen.Ghannam@amd.com > > v1->v2: > * Add parantheses around "bits" expression in macro. > * Fix indentation on multi-line statements. > > drivers/firmware/efi/cper-x86.c | 53 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-x86.c > index 9da0d981178f..417bd4e500a7 100644 > --- a/drivers/firmware/efi/cper-x86.c > +++ b/drivers/firmware/efi/cper-x86.c > @@ -3,15 +3,28 @@ > > #include > > +#define INDENT_SP " " That's just silly. > + > /* > * We don't need a "CPER_IA" prefix since these are all locally defined. > * This will save us a lot of line space. > */ > #define VALID_LAPIC_ID BIT_ULL(0) > #define VALID_CPUID_INFO BIT_ULL(1) > +#define VALID_PROC_ERR_INFO_NUM(bits) (((bits) & GENMASK_ULL(7, 2)) >> 2) > + > +#define INFO_VALID_CHECK_INFO BIT_ULL(0) > +#define INFO_VALID_TARGET_ID BIT_ULL(1) > +#define INFO_VALID_REQUESTOR_ID BIT_ULL(2) > +#define INFO_VALID_RESPONDER_ID BIT_ULL(3) > +#define INFO_VALID_IP BIT_ULL(4) > > void cper_print_proc_ia(const char *pfx, const struct cper_sec_proc_ia *proc) > { > + int i; > + struct cper_ia_err_info *err_info; > + char newpfx[64]; > + > printk("%sValidation Bits: 0x%016llx\n", pfx, proc->validation_bits); > > if (proc->validation_bits & VALID_LAPIC_ID) > @@ -22,4 +35,44 @@ void cper_print_proc_ia(const char *pfx, const struct cper_sec_proc_ia *proc) > print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, proc->cpuid, > sizeof(proc->cpuid), 0); > } > + > + snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP); > + > + err_info = (struct cper_ia_err_info *)(proc + 1); > + for (i = 0; i < VALID_PROC_ERR_INFO_NUM(proc->validation_bits); i++) { > + printk("%sError Information Structure %d:\n", pfx, i); > + > + printk("%sError Structure Type: %pUl\n", newpfx, > + &err_info->err_type); That dumps a GUID - how do I find out what type that GUID refers to? > + > + printk("%sValidation Bits: 0x%016llx\n", > + newpfx, err_info->validation_bits); As before, no need for those. > + > + if (err_info->validation_bits & INFO_VALID_CHECK_INFO) { > + printk("%sCheck Information: 0x%016llx\n", newpfx, > + err_info->check_info); > + } > + > + if (err_info->validation_bits & INFO_VALID_TARGET_ID) { > + printk("%sTarget Identifier: 0x%016llx\n", > + newpfx, err_info->target_id); > + } > + > + if (err_info->validation_bits & INFO_VALID_REQUESTOR_ID) { > + printk("%sRequestor Identifier: 0x%016llx\n", > + newpfx, err_info->requestor_id); > + } > + > + if (err_info->validation_bits & INFO_VALID_RESPONDER_ID) { > + printk("%sResponder Identifier: 0x%016llx\n", > + newpfx, err_info->responder_id); > + } Those look like would need an additional decoding. Can we do that here too? > + > + if (err_info->validation_bits & INFO_VALID_IP) { > + printk("%sInstruction Pointer: 0x%016llx\n", > + newpfx, err_info->ip); The only thing that makes sense so far. > + } > + > + err_info++; > + } Also, it is worth checking how much duplication there is with drivers/firmware/efi/cper-arm.c and unifying the common pieces into functions in cper-common.c or so. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --