Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1947472AbdDYQbM (ORCPT ); Tue, 25 Apr 2017 12:31:12 -0400 Received: from mail.skyhub.de ([5.9.137.197]:54130 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1431767AbdDYQbE (ORCPT ); Tue, 25 Apr 2017 12:31:04 -0400 Date: Tue, 25 Apr 2017 18:31:01 +0200 From: Borislav Petkov To: "Baicar, Tyler" Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com, pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, matt@codeblueprint.co.uk, robert.moore@intel.com, lv.zheng@intel.com, nkaje@codeaurora.org, zjzhang@codeaurora.org, mark.rutland@arm.com, james.morse@arm.com, akpm@linux-foundation.org, eun.taik.lee@samsung.com, sandeepa.s.prabhu@gmail.com, labbott@redhat.com, shijie.huang@arm.com, rruigrok@codeaurora.org, paul.gortmaker@windriver.com, tn@semihalf.com, fu.wei@linaro.org, rostedt@goodmis.org, bristot@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, Suzuki.Poulose@arm.com, punit.agrawal@arm.com, astone@redhat.com, harba@codeaurora.org, hanjun.guo@linaro.org, john.garry@huawei.com, shiju.jose@huawei.com, joe@perches.com, rafael@kernel.org, tony.luck@intel.com, gengdongjiu@huawei.com, xiexiuqi@huawei.com Subject: Re: [PATCH V15 04/11] efi: parse ARM processor error Message-ID: <20170425163101.oygshqqz2ik6te3f@pd.tnic> References: <1492556723-9189-1-git-send-email-tbaicar@codeaurora.org> <1492556723-9189-5-git-send-email-tbaicar@codeaurora.org> <20170421175527.fjwnqd22jz7br5yu@pd.tnic> <20170424175240.3nvhbxzwicxnk6og@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1630 Lines: 37 On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with > vendor specific error decoding. Currently we are using the RAS Daemon user > space tool for the decoding of this information since vendors can easily > pick up this tool and add an extension for their vendor specific parsing. > These prints will only happen when the firmware supports the vendor specific > error information anyway. The same questions apply here: what do you do if the machine panics because the error is fatal and you can't get it to run any userspace? Wouldn't it be good to decode the whole error? Right now we photograph screens on Intel x86 and feed the typed MCA info by hand to mcelog. Hardly an optimal situation. On AMD, there's a decoder which actually can dump the decoded critical error. (Or could - that's in flux again :-\). So yes, if stuff is too vendor-specific then you probably don't want to decode it (or add a vendor-specific decoding module like edac_mce_amd.ko, for example). But the tables from the UEFI spec, documenting IP-specific error types which should be valid for most if not all ARM64 implementations adhering to the spec, would be useful to decode. In general, the more we can decode the error in the kernel and the less we need an external help to do so, the better. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.