From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: <linux-edac@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-efi@vger.kernel.org>
Cc: <linuxarm@huawei.com>, <rjw@rjwysocki.net>, <tony.luck@intel.com>,
<bp@alien8.de>, <james.morse@arm.com>,
<ard.beisheuvel@linaro.org>, <nariman.poushin@linaro.org>
Subject: Re: [RFC PATCH 0/6] CCIX Protocol Error reporting
Date: Tue, 25 Jun 2019 12:34:34 +0100 [thread overview]
Message-ID: <20190625123434.00005d50@huawei.com> (raw)
In-Reply-To: <20190606123654.78973-1-Jonathan.Cameron@huawei.com>
On Thu, 6 Jun 2019 20:36:48 +0800
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
Hi All,
I'm looking for some reviews on this series if anyone has time to take
a look. Rasdaemon patches to match with this are on linux-edac but
are waiting on the tracepoints merging.
I'm not currently planning to upstream the qemu injection patches
used to test this but anyone would like those I can certainly put
a public branch up somewhere.
Thanks,
Jonathan
> UEFI 2.8 defines a new CPER record Appendix N for CCIX Protocol Error Records
> (PER). www.uefi.org
>
> These include Protocol Error Record logs which are defined in the
> CCIX 1.0 Base Specification www.ccixconsortium.com.
>
> Handling of coherency protocol errors is complex and how Linux does this
> will take some time to evolve. For now, fatal errors are handled via the
> usual means and everything else is reported.
>
> There are 6 types of error defined, covering:
> * Memory errors
> * Cache errors
> * Address translation unit errors
> * CCIX port errors
> * CCIX link errors
> * Agent internal errors.
>
> The set includes tracepoints to report the errors to RAS Daemon and a patch
> set for RAS Daemon will follow shortly.
>
> There are several open questions for this RFC.
> 1. Reporting of vendor data. We have little choice but to do this via a
> dynamic array as these blocks can take arbitrary size. I had hoped
> no one would actually use these given the odd mismatch between a
> standard error structure and non standard element, but there are
> already designs out there that do use it.
> 2. The trade off between explicit tracepoint fields, on which we might
> want to filter, and the simplicity of a blob. I have gone for having
> the whole of the block specific to the PER error type in an opaque blob.
> Perhaps this is not the right balance?
> 3. Whether defining 6 new tracepoints is sensible. I think it is:
> * They are all defined by the CCIX specification as independant error
> classes.
> * Many of them can only be generated by particular types of agent.
> * The handling required will vary widely depending on types.
> In the kernel some map cleanly onto existing handling. Keeping the
> whole flow separate will aide this. They vary by a similar amount
> in scope to the RAS errors found on an existing system which have
> independent tracepoints.
> * Separating them out allows for filtering on the tracepoints by
> elements that are not shared between them.
> * Muxing the lot into one record type can lead to ugly code both in
> kernel and in userspace.
>
> Rasdaemon patches will follow shortly.
>
> This patch is being distributed by the CCIX Consortium, Inc. (CCIX) to
> you and other parties that are paticipating (the "participants") in the
> Linux kernel with the understanding that the participants will use CCIX's
> name and trademark only when this patch is used in association with the
> Linux kernel and associated user space.
>
> CCIX is also distributing this patch to these participants with the
> understanding that if any portion of the CCIX specification will be
> used or referenced in the Linux kernel, the participants will not modify
> the cited portion of the CCIX specification and will give CCIX propery
> copyright attribution by including the following copyright notice with
> the cited part of the CCIX specification:
> "© 2019 CCIX CONSORTIUM, INC. ALL RIGHTS RESERVED."
>
> Jonathan Cameron (6):
> efi / ras: CCIX Memory error reporting
> efi / ras: CCIX Cache error reporting
> efi / ras: CCIX Address Translation Cache error reporting
> efi / ras: CCIX Port error reporting
> efi / ras: CCIX Link error reporting
> efi / ras: CCIX Agent internal error reporting
>
> drivers/acpi/apei/Kconfig | 8 +
> drivers/acpi/apei/ghes.c | 59 ++
> drivers/firmware/efi/Kconfig | 5 +
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/cper-ccix.c | 916 +++++++++++++++++++++++++++++++
> drivers/firmware/efi/cper.c | 6 +
> include/linux/cper.h | 333 +++++++++++
> include/ras/ras_event.h | 405 ++++++++++++++
> 8 files changed, 1733 insertions(+)
> create mode 100644 drivers/firmware/efi/cper-ccix.c
>
next prev parent reply other threads:[~2019-06-25 11:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 12:36 [RFC PATCH 0/6] CCIX Protocol Error reporting Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 1/6] efi / ras: CCIX Memory error reporting Jonathan Cameron
2019-06-21 17:40 ` Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 2/6] efi / ras: CCIX Cache " Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 3/6] efi / ras: CCIX Address Translation " Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 4/6] efi / ras: CCIX Port " Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 5/6] efi / ras: CCIX Link " Jonathan Cameron
2019-06-06 12:36 ` [RFC PATCH 6/6] efi / ras: CCIX Agent internal " Jonathan Cameron
2019-06-25 11:34 ` Jonathan Cameron [this message]
2019-07-03 9:28 ` [RFC PATCH 0/6] CCIX Protocol Error reporting James Morse
2019-07-03 13:08 ` Jonathan Cameron
2019-08-06 11:14 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190625123434.00005d50@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=ard.beisheuvel@linaro.org \
--cc=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=nariman.poushin@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.