Hi gengdongjiu,

On 11/09/17 13:04, gengdongjiu wrote:

On 2017/9/9 2:17, James Morse wrote:

quoted

On 04/09/17 12:43, gengdongjiu wrote:

quoted

On 2017/9/1 1:50, James Morse wrote:

quoted

On 28/08/17 11:38, Dongjiu Geng wrote:
If you aren't handling the notification, why is this is in the HEST at all?
(and if its not: its not firmware-first)

quoted

For the SEI notification, may be we can parse and handle the CPER record other than the Error physical address

Sure, but I only see this cleanup patch in this series, where does APEI learn
about NOTIFY_SEI? As this is nothing will ever touch those CPER records, if
you're using GHESv2 firmware will be prevented from delivering subsequent
notifications.

James, whether it is possible you can review the previous v5 patch which adds the support for

Spreading 'current discussion' over two versions is a problem for anyone trying
to follow this series.

If you post a newer version its normal for people to delete the older versions.
When you post a new version you should be happy that its the latest and greatest.

NOTIFY_SEI? thanks in advancecIn that patch, I share the SEI notification

handling with the SEA

notification handling to avoid duplicated code.

You may be able to share some of the code, but I don't think you should share
the list of GHES between notification methods.
This leads to races between the firmware and OS: If CPU-A has received an SEI
firmware would have to avoid generating an SEA on CPU-B as the SEI-handler
running on CPU-A may find and process the second set of CPER records. CPU-B then
gets a spurious notification.

Why is this a problem? KVM needs to know if APEI handled the error, or whether
the Synchronous-External-Abort/SError-Interrupt was due to something else, in
which case we invoke todays default behaviour, which isn't appropriate for a RAS
event.


Thanks,

James