Parse PELs sent by OpenPOWER host firmware

[Vasant Hegde]

On 03/13/2018 07:09 PM, Deepak Kodihalli wrote:
> Hi,
> 
> The SELs/eSELs (System Event Log) that OpenBMC receives from hostboot/skiboot 
> today are not interpreted, and are dumped as-is in a property of the error log 
> D-Bus object. This means that if there's a PEL (Platform Event Log) hidden in 
> the eSEL, admins/users of the error log need to depend on external tools to 
> parse the PEL to human readable text.

Yes.  We are having hard time with this. Any improvement is welcome.


> 
> Here's a proposal to have the BMC itself parse such eSELs (the motivation is to 
> make the OpenBMC error logs more useful in this context, without needing the 
> extra steps to parse such errors) :
> 
> - Separate this from phosphor-logging. This code can't go to a phosphor app, 
> because it's OpenPOWER specific. Have, for example, an openpower-logging app 
> implement a D-Bus interface to parse out a PEL from an eSEL. This app will host 
> it's own D-Bus service.
> 
> - Such an app can watch for error D-Bus objects being created in the phosphor 
> namespace. If it finds an eSEL in an error log, it can attempt to parse a PEL 
> (if there's one), and store the PELs parsed text representation in a D-Bus 
> property.
> 
> - The app can create a D-Bus object with the same path as the original object 
> and have a D-Bus object-manager at the error log root path, so that when someone 
> uses the OpenBMC REST API to read an error log, properties across all D-Bus 
> services will be returned (phosphor-rest-server does this today already). This 
> means with the existing REST API to enumerate error logs, a parsed PEL would be 
> returned, if present.
> 
> - To parse the PEL, use opal-elog-parse.

+1. I think it has capability to detect eSEL wrapper as well. It should just 
work fine.

-Vasant