From: gengdongjiu <gengdongjiu@huawei.com>
To: Borislav Petkov <bp@suse.de>
Cc: <tbaicar@codeaurora.org>, <james.morse@arm.com>,
<will.deacon@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>,
<robert.moore@intel.com>, <lv.zheng@intel.com>,
<mark.rutland@arm.com>, <kristina.martsenko@arm.com>,
<mingo@kernel.org>, <punit.agrawal@arm.com>,
<stephen.boyd@linaro.org>, <kamensky@cisco.com>,
<prarit@redhat.com>, <shiju.jose@huawei.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<devel@acpica.org>, Huangshaoyu <huangshaoyu@huawei.com>,
Wuquanming <wuquanming@huawei.com>
Subject: Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8
Date: Wed, 18 Oct 2017 13:00:44 +0800 [thread overview]
Message-ID: <0bcba052-700b-5ee8-88fc-aaf8cc6b1d37@huawei.com> (raw)
In-Reply-To: <20171017170635.qb4sqyrsnndgbuni@pd.tnic>
Hi Borislav,
On 2017/10/18 1:06, Borislav Petkov wrote:
> On Tue, Oct 17, 2017 at 04:02:21PM +0800, Dongjiu Geng wrote:
>> ARMv8.2 requires implementation of the RAS extension, in
>> this extension it adds SEI(SError Interrupt) notification
>> type, this patch adds new GHES error source SEI handling
>> functions. Because this error source parsing and handling
>> methods are similar with the SEA. So share some SEA handling
>> functions with the SEI
>>
>> Expose one API ghes_notify_abort() to external users. External
>> modules can call this exposed API to parse and handle the
>> SEA or SEI.
>>
>> Note: For the SEI(SError Interrupt), it is asynchronous external
>> abort, the error address recorded by firmware may be not accurate.
>> If not accurate, EL3 firmware needs to identify the address to a
>> invalid value.
>>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: James Morse <james.morse@arm.com>
>> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
>> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Tested-by: Dongjiu Geng <gengdongjiu@huawei.com>
>> ---
>> arch/arm64/mm/fault.c | 4 +--
>> drivers/acpi/apei/Kconfig | 15 ++++++++++
>> drivers/acpi/apei/ghes.c | 71 ++++++++++++++++++++++++++++++++++-------------
>> include/acpi/ghes.h | 2 +-
>> 4 files changed, 70 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 2509e4f..c98c1b3 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -585,7 +585,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> if (interrupts_enabled(regs))
>> nmi_enter();
>>
>> - ret = ghes_notify_sea();
>> + ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>
>> if (interrupts_enabled(regs))
>> nmi_exit();
>> @@ -682,7 +682,7 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
>> int ret = -ENOENT;
>>
>> if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
>> - ret = ghes_notify_sea();
>> + ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>
>> return ret;
>> }
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index de14d49..47fcb0c 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -54,6 +54,21 @@ config ACPI_APEI_SEA
>> option allows the OS to look for such hardware error record, and
>> take appropriate action.
>>
>> +config ACPI_APEI_SEI
>> + bool "APEI Asynchronous SError Interrupt logging/recovering support"
>
> What is "SError" ?
SError is System Error, which is a asynchronous exception in the Internal CPU.
In the ARM RAS Extension, there are mainly two type abort for CPU:
SEA(Synchronous External Abort)
SEI(SError Interrupt)
>
>> + depends on ARM64 && ACPI_APEI_GHES
>> + default y
>> + help
>> + This option should be enabled if the system supports
>> + firmware first handling of SEI (asynchronous SError interrupt).
>> +
>> + SEI happens with asynchronous external abort for errors on device
>> + memory reads on ARMv8 systems. If a system supports firmware first
>> + handling of SEI, the platform analyzes and handles hardware error
>> + notifications from SEI, and it may then form a HW error record for
>> + the OS to parse and handle. This option allows the OS to look for
>> + such hardware error record, and take appropriate action.
>> +
>> config ACPI_APEI_MEMORY_FAILURE
>> bool "APEI memory error recovering support"
>> depends on ACPI_APEI && MEMORY_FAILURE
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 3eee30a..24b4233 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -815,43 +815,67 @@ static struct notifier_block ghes_notifier_hed = {
>>
>> #ifdef CONFIG_ACPI_APEI_SEA
>> static LIST_HEAD(ghes_sea);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +#endif
>>
>> +#if defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ACPI_APEI_SEI)
>> /*
>> - * Return 0 only if one of the SEA error sources successfully reported an error
>> - * record sent from the firmware.
>> + * Return 0 only if one of the SEA or SEI error sources successfully
>> + * reported an error record sent from the firmware.
>> */
>> -int ghes_notify_sea(void)
>> +int ghes_notify_abort(u8 type)
>
> Adding "abort" everywhere makes it worse: what does this function now
> do, notify or abort or both?
This function is used to notify APEI driver to parse APEI table and do some
recovery, such as calling memrory_failure() to identify the address to a
poisoned memory and deliver SIGBUS to related application.
>
> Ditto for the remaining ones. Please think of a better name.
Ok, thanks for your good suggestion, I will consider to use a better name.
>
>
> ghes_notify_sei() sounds much better to me, for example. And then you
> can add a whole set of *_sei() functions similar to the *_sea() ones and
> then you don't have to do all that checking of the type but simply call
> the proper function set. They're not huge so that the duplication of
> code should be minimal.
Thanks for your suggestion again. I will flowing that and add a whole set
of *sei() functions.
>
next prev parent reply other threads:[~2017-10-18 5:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 8:02 [PATCH v5 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type Dongjiu Geng
2017-10-17 8:02 ` [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8 Dongjiu Geng
2017-10-17 17:06 ` Borislav Petkov
2017-10-18 5:00 ` gengdongjiu [this message]
2017-10-18 9:06 ` Borislav Petkov
2017-10-18 9:17 ` gengdongjiu
2017-10-18 9:25 ` Borislav Petkov
2017-10-18 9:44 ` James Morse
2017-10-18 10:04 ` Borislav Petkov
2017-10-18 10:25 ` gengdongjiu
2017-10-18 10:21 ` gengdongjiu
2017-10-18 10:26 ` James Morse
2017-10-18 11:39 ` gengdongjiu
2017-10-17 14:06 ` [PATCH v5 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type Tyler Baicar
2017-10-17 16:43 ` Borislav Petkov
2017-10-18 3:04 ` gengdongjiu
2017-10-18 10:17 ` Borislav Petkov
2017-10-18 12:27 ` gengdongjiu
2017-10-18 13:14 ` Borislav Petkov
2017-10-18 15:04 [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8 gengdongjiu
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=0bcba052-700b-5ee8-88fc-aaf8cc6b1d37@huawei.com \
--to=gengdongjiu@huawei.com \
--cc=bp@suse.de \
--cc=devel@acpica.org \
--cc=huangshaoyu@huawei.com \
--cc=james.morse@arm.com \
--cc=kamensky@cisco.com \
--cc=kristina.martsenko@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=prarit@redhat.com \
--cc=punit.agrawal@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=shiju.jose@huawei.com \
--cc=stephen.boyd@linaro.org \
--cc=tbaicar@codeaurora.org \
--cc=will.deacon@arm.com \
--cc=wuquanming@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®