SMBIOS / DMI Event Logs in Linux?

SMBIOS / DMI Event Logs in Linux?

[Mike Waychison]

Hey guys,

I need some guidance. Do either of you know of any attempts to have the 
kernel decode and display/interact with DMI type 15: System Event Log?

The event log I'm dealing with while cleaning up the "gsmi" driver 
interacts with a log that is modeled after the System Event Log.  I'm 
wondering if there is any precedent for a clean way to expose the event 
log, I'd like to use it (replacing the ioctls from my earlier patch 
series send-out).

FYI, we use OEM specific headers and descriptors, which probably doesn't 
help.

Do most folks that need access to this data rely on /dev/mem and 
dmidecode?  I'd like to avoid going that route if possible.

Lacking any better ideas though, I was thinking of something along the 
lines of the following:


$ cat /sys/firmware/gsmi/eventlog
<offset> <boot number> <recorded time> <quoted reason> <optional data>
...

with a single event log entry per line.
   <offset> would be the record number,
   <boot number> is the recorded boot number
   <recorded time> comes from each record,
   <quoted reason> is the English translation of Event Log Types from 
the DMTF standard + vendor extended types we use.
   <optional data> is space separated values associated with <quoted reason>

We also have a interfaces for clearing a fraction of the log, which I'm 
thinking is probably best expressed as a value of 0 through 100 written 
to a file, maybe /sys/firmware/gsmi/clear_eventlog ?

As well, we need to export to userland a way to append data to the log. 
  I was thinking we could write a parser to take in an entry and ensure 
it is well-formatted, but I'm a little hesitant to go this route as our 
records embed a timestamp, which I'd rather not have to figure out from 
within the kernel.  Perhaps a raw (binary) interface to write records to 
the log would suffice?  /sys/firmware/gsmi/append_to_eventlog ?

If so, does /sys/firmware/gsmi/raw_eventlog make sense too?


Thanks,

Mike Waychison

Re: SMBIOS / DMI Event Logs in Linux?

[Greg KH]

On Thu, Feb 10, 2011 at 03:18:14PM -0800, Mike Waychison wrote:
> Hey guys,
> 
> I need some guidance. Do either of you know of any attempts to have
> the kernel decode and display/interact with DMI type 15: System
> Event Log?

I don't have any experience in this area, but I do have one comment on
your proposal below:

> The event log I'm dealing with while cleaning up the "gsmi" driver
> interacts with a log that is modeled after the System Event Log.
> I'm wondering if there is any precedent for a clean way to expose
> the event log, I'd like to use it (replacing the ioctls from my
> earlier patch series send-out).
> 
> FYI, we use OEM specific headers and descriptors, which probably
> doesn't help.
> 
> Do most folks that need access to this data rely on /dev/mem and
> dmidecode?  I'd like to avoid going that route if possible.
> 
> Lacking any better ideas though, I was thinking of something along
> the lines of the following:
> 
> 
> $ cat /sys/firmware/gsmi/eventlog
> <offset> <boot number> <recorded time> <quoted reason> <optional data>
> ...
> 
> with a single event log entry per line.
>   <offset> would be the record number,
>   <boot number> is the recorded boot number
>   <recorded time> comes from each record,
>   <quoted reason> is the English translation of Event Log Types from
> the DMTF standard + vendor extended types we use.
>   <optional data> is space separated values associated with <quoted reason>

Ick, no, remember, sysfs is "one value per file".  doing even a single
line like you describe here isn't ok, not to mention a huge buffer of
these lines.

And no, a "binary" sysfs file is not ok either.

Now your idea for such a log file is fine, I'm not saying that's not ok,
or acceptable, just don't put it in sysfs, sorry.  Try using the ring
buffer framework from the tracing code perhaps?

Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
together if you need it.

thanks,

greg k-h

Re: SMBIOS / DMI Event Logs in Linux?

[Mike Waychison]

On 02/10/11 17:25, Greg KH wrote:
> On Thu, Feb 10, 2011 at 03:18:14PM -0800, Mike Waychison wrote:
>> Hey guys,
>>
>> I need some guidance. Do either of you know of any attempts to have
>> the kernel decode and display/interact with DMI type 15: System
>> Event Log?
>
> I don't have any experience in this area, but I do have one comment on
> your proposal below:
>
>> The event log I'm dealing with while cleaning up the "gsmi" driver
>> interacts with a log that is modeled after the System Event Log.
>> I'm wondering if there is any precedent for a clean way to expose
>> the event log, I'd like to use it (replacing the ioctls from my
>> earlier patch series send-out).
>>
>> FYI, we use OEM specific headers and descriptors, which probably
>> doesn't help.
>>
>> Do most folks that need access to this data rely on /dev/mem and
>> dmidecode?  I'd like to avoid going that route if possible.
>>
>> Lacking any better ideas though, I was thinking of something along
>> the lines of the following:
>>
>>
>> $ cat /sys/firmware/gsmi/eventlog
>> <offset>  <boot number>  <recorded time>  <quoted reason>  <optional data>
>> ...
>>
>> with a single event log entry per line.
>>    <offset>  would be the record number,
>>    <boot number>  is the recorded boot number
>>    <recorded time>  comes from each record,
>>    <quoted reason>  is the English translation of Event Log Types from
>> the DMTF standard + vendor extended types we use.
>>    <optional data>  is space separated values associated with<quoted reason>
>
> Ick, no, remember, sysfs is "one value per file".  doing even a single
> line like you describe here isn't ok, not to mention a huge buffer of
> these lines.
>
> And no, a "binary" sysfs file is not ok either.

Works fine for the /sys/firmware/efi stuff.  Works well enough for 
/sys/firmware/acpi too.

>
> Now your idea for such a log file is fine, I'm not saying that's not ok,
> or acceptable, just don't put it in sysfs, sorry.  Try using the ring
> buffer framework from the tracing code perhaps?
>
> Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
> together if you need it.

Are you seriously asking for another filesystem?

I don't get why you're holding me to these standards that that are 
totally missed by these same subsystems that you maintain.

Re: SMBIOS / DMI Event Logs in Linux?

[Greg KH]

On Thu, Feb 10, 2011 at 06:19:47PM -0800, Mike Waychison wrote:
> On 02/10/11 17:25, Greg KH wrote:
> >On Thu, Feb 10, 2011 at 03:18:14PM -0800, Mike Waychison wrote:
> >>Hey guys,
> >>
> >>I need some guidance. Do either of you know of any attempts to have
> >>the kernel decode and display/interact with DMI type 15: System
> >>Event Log?
> >
> >I don't have any experience in this area, but I do have one comment on
> >your proposal below:
> >
> >>The event log I'm dealing with while cleaning up the "gsmi" driver
> >>interacts with a log that is modeled after the System Event Log.
> >>I'm wondering if there is any precedent for a clean way to expose
> >>the event log, I'd like to use it (replacing the ioctls from my
> >>earlier patch series send-out).
> >>
> >>FYI, we use OEM specific headers and descriptors, which probably
> >>doesn't help.
> >>
> >>Do most folks that need access to this data rely on /dev/mem and
> >>dmidecode?  I'd like to avoid going that route if possible.
> >>
> >>Lacking any better ideas though, I was thinking of something along
> >>the lines of the following:
> >>
> >>
> >>$ cat /sys/firmware/gsmi/eventlog
> >><offset>  <boot number>  <recorded time>  <quoted reason>  <optional data>
> >>...
> >>
> >>with a single event log entry per line.
> >>   <offset>  would be the record number,
> >>   <boot number>  is the recorded boot number
> >>   <recorded time>  comes from each record,
> >>   <quoted reason>  is the English translation of Event Log Types from
> >>the DMTF standard + vendor extended types we use.
> >>   <optional data>  is space separated values associated with<quoted reason>
> >
> >Ick, no, remember, sysfs is "one value per file".  doing even a single
> >line like you describe here isn't ok, not to mention a huge buffer of
> >these lines.
> >
> >And no, a "binary" sysfs file is not ok either.
> 
> Works fine for the /sys/firmware/efi stuff.

Do any of those files have multiple lines?  I don't have a system here
that has that directory.

> Works well enough for /sys/firmware/acpi too.

Those all look to be "one value per file" as well.

I don't see any long logs in these firmware types, or am I missing
something?

> >Now your idea for such a log file is fine, I'm not saying that's not ok,
> >or acceptable, just don't put it in sysfs, sorry.  Try using the ring
> >buffer framework from the tracing code perhaps?
> >
> >Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
> >together if you need it.
> 
> Are you seriously asking for another filesystem?

What's to be afraid of another filesystem?  It's only 250 lines of code,
and trivial to create.

Remember, sysfs almost was a filesystem-per-device implementation, as
our superblock and mounting logic is very nice and easy to handle all
race conditions.  I objected to that as it would be a bit unwieldy for
some filesystem mount lists, but the idea is still quite sane and
reasonable.

And also, a filesystem-per-type is just fine.  It uniquely keeps things
separate, and defines interfaces properly.

> I don't get why you're holding me to these standards that that are
> totally missed by these same subsystems that you maintain.

I do not see any files in the subsystems I maintain that have multiple
values per lines, and have multiple lines, in sysfs files.  What have I
missed that you are noticing?

thanks,

greg k-h

Re: SMBIOS / DMI Event Logs in Linux?

[Tim Hockin]

Caveat: I kind of loathe the proliferation of single use filesystems
for things that just aren't well mapped to the model.

That said, maybe smbiosfs is not so horrible of a mapping.  I'm
reticent to dredge up my spec, but I think it fits well enough, and
you can can leave most OEM-specific processing in userspace.

So for the type 15, something like:

/smbios/              # mountpoint
    15/                  # record type (decimal)
        0/                # instance number (decimal)
            change_token # change token from the type 15 struct
            header    # binary dump of the header section (if present)
            0/            # one dir for each record (decimal)
                id        # event ID (decimal)
                id_str  # event ID (stringified, if possible)
                size    # event size (decimal, bytes)
                timestamp   # year, month, day, hour, minute, second
                data   # binary dump of the payload
                raw    # binary dump of the whole event

This does not handle type descriptors, but I know *we* don't use them..

This does not address operations such as clearing the log or writing a
new event or locking/unlocking the log.  If there's an OEM-specific
driver loaded it could augment the above.

            clear_log       # write a number to this to clear some
percent of the log
            write_events # write a binary dump of an event, including timestamp?

I don't hate it.  IT would be cool to have all of SMBIOS available this way.

I'm not sure its worth the work, though.  Most Type 15 logs are in
memory-mapped ROM or in RAM, so tools can access it via /dev/mem (if
you have privs to do so).  I thought the SMI ioctl() interface worked
just fine for logging and clearing.  And hell, we could do that from
userspace if we had to, it's just IO ports, I think.  Maybe you need a
userspace V-to-P translation, too.

Tim


On Thu, Feb 10, 2011 at 5:25 PM, Greg KH <greg@kroah.com> wrote:
> On Thu, Feb 10, 2011 at 03:18:14PM -0800, Mike Waychison wrote:
>> Hey guys,
>>
>> I need some guidance. Do either of you know of any attempts to have
>> the kernel decode and display/interact with DMI type 15: System
>> Event Log?
>
> I don't have any experience in this area, but I do have one comment on
> your proposal below:
>
>> The event log I'm dealing with while cleaning up the "gsmi" driver
>> interacts with a log that is modeled after the System Event Log.
>> I'm wondering if there is any precedent for a clean way to expose
>> the event log, I'd like to use it (replacing the ioctls from my
>> earlier patch series send-out).
>>
>> FYI, we use OEM specific headers and descriptors, which probably
>> doesn't help.
>>
>> Do most folks that need access to this data rely on /dev/mem and
>> dmidecode?  I'd like to avoid going that route if possible.
>>
>> Lacking any better ideas though, I was thinking of something along
>> the lines of the following:
>>
>>
>> $ cat /sys/firmware/gsmi/eventlog
>> <offset> <boot number> <recorded time> <quoted reason> <optional data>
>> ...
>>
>> with a single event log entry per line.
>>   <offset> would be the record number,
>>   <boot number> is the recorded boot number
>>   <recorded time> comes from each record,
>>   <quoted reason> is the English translation of Event Log Types from
>> the DMTF standard + vendor extended types we use.
>>   <optional data> is space separated values associated with <quoted reason>
>
> Ick, no, remember, sysfs is "one value per file".  doing even a single
> line like you describe here isn't ok, not to mention a huge buffer of
> these lines.
>
> And no, a "binary" sysfs file is not ok either.
>
> Now your idea for such a log file is fine, I'm not saying that's not ok,
> or acceptable, just don't put it in sysfs, sorry.  Try using the ring
> buffer framework from the tracing code perhaps?
>
> Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
> together if you need it.
>
> thanks,
>
> greg k-h
>

Re: SMBIOS / DMI Event Logs in Linux?

[Greg KH]

On Thu, Feb 10, 2011 at 06:20:52PM -0800, Tim Hockin wrote:
> Caveat: I kind of loathe the proliferation of single use filesystems
> for things that just aren't well mapped to the model.
> 
> That said, maybe smbiosfs is not so horrible of a mapping.  I'm
> reticent to dredge up my spec, but I think it fits well enough, and
> you can can leave most OEM-specific processing in userspace.
> 
> So for the type 15, something like:
> 
> /smbios/              # mountpoint
>     15/                  # record type (decimal)
>         0/                # instance number (decimal)
>             change_token # change token from the type 15 struct
>             header    # binary dump of the header section (if present)
>             0/            # one dir for each record (decimal)
>                 id        # event ID (decimal)
>                 id_str  # event ID (stringified, if possible)
>                 size    # event size (decimal, bytes)
>                 timestamp   # year, month, day, hour, minute, second
>                 data   # binary dump of the payload
>                 raw    # binary dump of the whole event
> 
> This does not handle type descriptors, but I know *we* don't use them..
> 
> This does not address operations such as clearing the log or writing a
> new event or locking/unlocking the log.  If there's an OEM-specific
> driver loaded it could augment the above.
> 
>             clear_log       # write a number to this to clear some
> percent of the log
>             write_events # write a binary dump of an event, including timestamp?
> 
> I don't hate it.  IT would be cool to have all of SMBIOS available this way.
> 
> I'm not sure its worth the work, though.  Most Type 15 logs are in
> memory-mapped ROM or in RAM, so tools can access it via /dev/mem (if
> you have privs to do so).

Wait, if this is just a simple "pass through to the hardware", then just
export the thing, with the proper permissions, in a single binary sysfs
file, and do the parsing in userspace.

That would be the simplest thing to do, and fit the rules for valid
sysfs files, and keep people from having to dig through /dev/mem, right?

thanks,

greg k-h

Re: SMBIOS / DMI Event Logs in Linux?

[Mike Waychison]

resend as plain text, sorry :(


On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <greg@kroah.com> wrote:
> Wait, if this is just a simple "pass through to the hardware", then just
> export the thing, with the proper permissions, in a single binary sysfs
> file, and do the parsing in userspace.
>

If you mean s/hardware/firmware/, then yes.

>
> That would be the simplest thing to do, and fit the rules for valid
> sysfs files, and keep people from having to dig through /dev/mem, right?

Yup, exposing the log via a bin_attribute and allowing for blobs to be
appended (with the firmware either accepting or rejecting the format
will do).

Re: SMBIOS / DMI Event Logs in Linux?

[Greg KH]

On Fri, Feb 11, 2011 at 10:00:37AM -0800, Mike Waychison wrote:
> resend as plain text, sorry :(
> 
> 
> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <greg@kroah.com> wrote:
> > Wait, if this is just a simple "pass through to the hardware", then just
> > export the thing, with the proper permissions, in a single binary sysfs
> > file, and do the parsing in userspace.
> >
> 
> If you mean s/hardware/firmware/, then yes.

Yes, sorry, that is what I ment.

> > That would be the simplest thing to do, and fit the rules for valid
> > sysfs files, and keep people from having to dig through /dev/mem, right?
> 
> Yup, exposing the log via a bin_attribute and allowing for blobs to be
> appended (with the firmware either accepting or rejecting the format
> will do).

Great, that should be a simple thing to do then, right?

greg k-h

Re: SMBIOS / DMI Event Logs in Linux?

[Mike Waychison]

On Fri, Feb 11, 2011 at 10:32 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Feb 11, 2011 at 10:00:37AM -0800, Mike Waychison wrote:
>> resend as plain text, sorry :(
>>
>>
>> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <greg@kroah.com> wrote:
>> > Wait, if this is just a simple "pass through to the hardware", then just
>> > export the thing, with the proper permissions, in a single binary sysfs
>> > file, and do the parsing in userspace.
>> >
>>
>> If you mean s/hardware/firmware/, then yes.
>
> Yes, sorry, that is what I ment.
>
>> > That would be the simplest thing to do, and fit the rules for valid
>> > sysfs files, and keep people from having to dig through /dev/mem, right?
>>
>> Yup, exposing the log via a bin_attribute and allowing for blobs to be
>> appended (with the firmware either accepting or rejecting the format
>> will do).
>
> Great, that should be a simple thing to do then, right?

Ya.  Here's what I'm working on now:

/sys/firmware/gsmi/eventlog
  - read: reads out binary bytes of the log as exported by firmware.
  - write: takes the user buffer and passes it on to the firmware via
a SET_EVENT_LOG command and returns a mapped errno to the user.

/sys/firmware/gsmi/clear_eventlog
  - write-only: takes a value between 0 and 100 and passes it to the
firmware to clear out a percentage of the log.

/sys/firmware/gsmi/clear_config
  - write-only: takes arbitrary data and tells the firmware to wipe it's config.

/sys/firmware/gsmi/vars (directory)
  - same code as /sys/firmware/efi/vars except firmware calls vector
through gsmi instead of the EFI runtime services page  (I've
abstracted it out for re-use)

This covers the gsmi driver and removes the ioctls completely from it.


I've already changed the "memconsole" driver I sent out a while ago to
export itself as an untouched binary file /sys/firmware/log .

The only bit that remains that needs cleaning is the 'bootlog' driver.
  I'm going to work with Robert offline (or online if he wants to
follow up here) with what "proper" kernel interfaces should look like
for his purposes.

Re: SMBIOS / DMI Event Logs in Linux?

[Greg KH]

On Fri, Feb 11, 2011 at 10:56:16AM -0800, Mike Waychison wrote:
> On Fri, Feb 11, 2011 at 10:32 AM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Feb 11, 2011 at 10:00:37AM -0800, Mike Waychison wrote:
> >> resend as plain text, sorry :(
> >>
> >>
> >> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <greg@kroah.com> wrote:
> >> > Wait, if this is just a simple "pass through to the hardware", then just
> >> > export the thing, with the proper permissions, in a single binary sysfs
> >> > file, and do the parsing in userspace.
> >> >
> >>
> >> If you mean s/hardware/firmware/, then yes.
> >
> > Yes, sorry, that is what I ment.
> >
> >> > That would be the simplest thing to do, and fit the rules for valid
> >> > sysfs files, and keep people from having to dig through /dev/mem, right?
> >>
> >> Yup, exposing the log via a bin_attribute and allowing for blobs to be
> >> appended (with the firmware either accepting or rejecting the format
> >> will do).
> >
> > Great, that should be a simple thing to do then, right?
> 
> Ya.  Here's what I'm working on now:
> 
> /sys/firmware/gsmi/eventlog
>   - read: reads out binary bytes of the log as exported by firmware.
>   - write: takes the user buffer and passes it on to the firmware via
> a SET_EVENT_LOG command and returns a mapped errno to the user.
> 
> /sys/firmware/gsmi/clear_eventlog
>   - write-only: takes a value between 0 and 100 and passes it to the
> firmware to clear out a percentage of the log.
> 
> /sys/firmware/gsmi/clear_config
>   - write-only: takes arbitrary data and tells the firmware to wipe it's config.
> 
> /sys/firmware/gsmi/vars (directory)
>   - same code as /sys/firmware/efi/vars except firmware calls vector
> through gsmi instead of the EFI runtime services page  (I've
> abstracted it out for re-use)
> 
> This covers the gsmi driver and removes the ioctls completely from it.

Wonderful, that should have hopefully also made the code cleaner.

> I've already changed the "memconsole" driver I sent out a while ago to
> export itself as an untouched binary file /sys/firmware/log .
> 
> The only bit that remains that needs cleaning is the 'bootlog' driver.
>   I'm going to work with Robert offline (or online if he wants to
> follow up here) with what "proper" kernel interfaces should look like
> for his purposes.

I thought that it was agreed that it too would be a binary sysfs file to
be read from?  Or was that me just wishing it would be so?  :)

thanks,

greg k-h

Re: SMBIOS / DMI Event Logs in Linux?

[Alan Cox]

> Now your idea for such a log file is fine, I'm not saying that's not ok,
> or acceptable, just don't put it in sysfs, sorry.  Try using the ring
> buffer framework from the tracing code perhaps?

Thats probably overkill unless you need to field messages very fast and
synchronize them with other trace data (in which case it's probably not
overkill)

> Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
> together if you need it.

netlink, connector, or even just a simple misc device that tosses them
down a kfifo ?

Alan

Re: SMBIOS / DMI Event Logs in Linux?

[Rob Lippert]

On Thu, Feb 10, 2011 at 3:18 PM, Mike Waychison <mikew@google.com> wrote:
> Hey guys,
>
> I need some guidance. Do either of you know of any attempts to have the
> kernel decode and display/interact with DMI type 15: System Event Log?
>

I don't know what the benefit of the having the kernel decode the SEL
would be besides the ability to printk() the contents during boot
time.
Since it generally contains vendor/OEM/machine specific data having to
have each vendor provide their own kernel module to decode seems like
a maintenance pain.  Also having the decoding in the kernel means that
adding any new event types requires respinning a kernel.

> The event log I'm dealing with while cleaning up the "gsmi" driver interacts
> with a log that is modeled after the System Event Log.  I'm wondering if
> there is any precedent for a clean way to expose the event log, I'd like to
> use it (replacing the ioctls from my earlier patch series send-out).
>
> FYI, we use OEM specific headers and descriptors, which probably doesn't
> help.
>
> Do most folks that need access to this data rely on /dev/mem and dmidecode?
>  I'd like to avoid going that route if possible.
>
> Lacking any better ideas though, I was thinking of something along the lines
> of the following:
>
>
> $ cat /sys/firmware/gsmi/eventlog
> <offset> <boot number> <recorded time> <quoted reason> <optional data>
> ...
>
> with a single event log entry per line.
>  <offset> would be the record number,
>  <boot number> is the recorded boot number
>  <recorded time> comes from each record,
>  <quoted reason> is the English translation of Event Log Types from the DMTF
> standard + vendor extended types we use.
>  <optional data> is space separated values associated with <quoted reason>
>

What about just exposing the "raw" bytes of the eventlog similar to
how the kernel currently exposes the ACPI tables at e.g.:

/sys/firmware/acpi/tables/DSDT

That would avoid the userspace app having to do the mmio or port io to
actually read the eventlog and the kernel can export it in a standard
fashion on any machine which supports an SMBIOS-style event log table.

> We also have a interfaces for clearing a fraction of the log, which I'm
> thinking is probably best expressed as a value of 0 through 100 written to a
> file, maybe /sys/firmware/gsmi/clear_eventlog ?
>

This is definitely a vendor-specific extension as I know some other
eventlog interfaces (like IPMI) support things like deleting
individual entries.

> As well, we need to export to userland a way to append data to the log.  I
> was thinking we could write a parser to take in an entry and ensure it is
> well-formatted, but I'm a little hesitant to go this route as our records
> embed a timestamp, which I'd rather not have to figure out from within the
> kernel.  Perhaps a raw (binary) interface to write records to the log would
> suffice?  /sys/firmware/gsmi/append_to_eventlog ?
>

Verification of the data is probably best left to the
BIOS/BMC/whatever that is storing the event data and that can return
an error back to userspace if a record is invalid.  Otherwise you're
again potentially duplicating the parsing/verifying work that is
already being done in userspace and the BIOS.

> If so, does /sys/firmware/gsmi/raw_eventlog make sense too?
>
>
> Thanks,
>
> Mike Waychison
>