[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <580C7F38.4010301@huawei.com>
Date: Sun, 23 Oct 2016 17:13:28 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: "Abdulhamid, Harb" <harba@...eaurora.org>,
Hanjun Guo <hanjun.guo@...aro.org>,
Tyler Baicar <tbaicar@...eaurora.org>,
<christoffer.dall@...aro.org>, <marc.zyngier@....com>,
<pbonzini@...hat.com>, <rkrcmar@...hat.com>,
<linux@...linux.org.uk>, <catalin.marinas@....com>,
<will.deacon@....com>, <rjw@...ysocki.net>, <lenb@...nel.org>,
<matt@...eblueprint.co.uk>, <robert.moore@...el.com>,
<lv.zheng@...el.com>, <mark.rutland@....com>,
<james.morse@....com>, <akpm@...ux-foundation.org>,
<sandeepa.s.prabhu@...il.com>, <shijie.huang@....com>,
<paul.gortmaker@...driver.com>, <tomasz.nowicki@...aro.org>,
<fu.wei@...aro.org>, <rostedt@...dmis.org>, <bristot@...hat.com>,
<linux-arm-kernel@...ts.infradead.org>,
<kvmarm@...ts.cs.columbia.edu>, <Dkvm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
<linux-efi@...r.kernel.org>, <devel@...ica.org>
CC: Naveen Kaje <nkaje@...eaurora.org>,
"Jonathan (Zhixiong) Zhang" <zjzhang@...eaurora.org>
Subject: Re: [PATCH V3 05/10] acpi: apei: handle SEA notification type for
ARMv8
Hi Harb,
On 2016/10/20 0:59, Abdulhamid, Harb wrote:
> On 10/18/2016 8:44 AM, Hanjun Guo wrote:
>> Hi Tyler,
>>
>> On 2016/10/8 5:31, Tyler Baicar wrote:
>>> ARM APEI extension proposal added SEA (Synchrounous External
>>> Abort) notification type for ARMv8.
>>> Add a new GHES error source handling function for SEA. If an error
>>> source's notification type is SEA, then this function can be registered
>>> into the SEA exception handler. That way GHES will parse and report
>>> SEA exceptions when they occur.
>> Does this SEA is replayed by the firmware (firmware first handling)
>> or directly triggered by the hardware when error is happened?
> Architecturally, an SEA must be synchronous and *precise*, so if you
> take an SEA on a particular load instruction, firmware/hardware should
> not be corrupting the context/state of the PE to allow software to
> determine which thread/process encountered the abort. GHES error status
That's my concern too, and that's why I raised my question :)
> block will be expose to software with information about the type,
> severity, physical address impacted.
>
> Generally the error status block is populated by firmware. However, as
> long as the above requirement is met, I don't think the spec precludes
> error status block being populated by hardware. Those details must be
> completely transparent to software.
>
> Finally, to answer your more specific question: If the implementation
> of firmware-first involves trapping the SEA in EL3 to do some firmware
> first handling, firmware must maintain the context of the offending ELx,
> generate an error record, and then "replay" the exception to normal
> (non-secure) software at the appropriate vector base address.
>
Thank you for your answer, it clears my confusion now, I will try something
similar on ARM64 platform, will get back to you if I get blocks.
Thanks
Hanjun
Powered by blists - more mailing lists