Lines Matching +full:implementation +full:- +full:specific
3 In many cases Manufacturers-specific IPMI Platfrom Events are stored in binary
8 events originating from Intel Management Engine (ME) is used as a case-study.
9 General design of the solution is followed by tailored-down implementation for
14 - **IPMI** - Intelligent Platform Management Interface; standarized binary
16 - **Platform Event** - specific type of IPMI binary payload, used for encoding
17 and sending asynchronous one-way messages to recipient `[1]-29.3`
18 - **ME** - Intel Management Engine, autonomous subsystem used for remote
20 - **Redfish** - modern datacenter management protocol, built around REST
22 - **OpenBMC** - open-source BMC implementation with Redfish-oriented interface
28 between entities in data-center. Recipient is responsible to receive data,
30 human-readable format. IPMI Platform Events is one type of these messages, used
34 and already have an open-source implementation ready `[6]`, however this is only
36 possible sources of events which are defined by manufacturer-specirfic
39 notify about certain erroneous system-wide conditions, like interface errors.
41 These OEM-specific messages lacks support in existing open-source
42 implementations. They require manual, documentation-based `[5]` implementation,
44 update requires manual code modification according to specific changes which is
45 not efficient nor scalable. Furthermore - documentation is not always clear on
50 Generic OEM-agnostic algorithm is proposed to achieve human-readable output for
61 - `GeneratorID` - used to determine source of the event,
62 - `SensorNumber` - generator-specific unique sensor number,
63 - `EventType` - sensor-specific group of events,
64 - `EventData` - array with detailed event data.
72 many OEM-specific IPMI implementations that is also the case.
74 Implementation should be therefore a series of filters with increasing
79 +-------------+ +*Step 1* +
80 | +---------+ | | |
82 +----> |analyzed +------------>+proper 'subtree' parser|
84 | | +---------+ | + + +---------+
85 | | +---------+ | |Remainder|
89 | | | +---------------------------------------------->+ +---+
93 | | +---------+ | | | |
94 | +-------------+ +---------+ |
97 +------------------------------------------------------------------------------+
100 Described process will be repeated until there is nothing to break-down and
103 Not all event data is a decision point - certain chunks of data should be kept
104 as-is or formatted in certain way, to be introduced in human-readable `Message`.
112 - `EventId` - associated unique event,
113 - `Severity` - determines how severely this particular event might affect usual
115 - `Resolution` - suggested steps to mitigate possible problem,
116 - `Message` - human-readable message, possibly with predefined placeholders for
124 +-------------+
127 +------+------+
129 +------v---------+
132 +------+---------+
134 +------v---------+
137 +------+---------+
139 +------v-------------------+
140 |[EventData[0]] | +-------------------------------------------+
141 . . . . |0x0A (FlashWearoutWarning)+------+ |ParsedEvent| |
142 +------+-------------------+ | +-----------+ |
143 | +---->'EventId' = FlashWearoutWarning |
144 +------v----------+ +---->'Parameters' = [ toDecimal(EventData[1]) ] |
146 |0x## (Percentage)+---------------+ +-------------------------------------------+
147 +-----------------+
151 contains human-readable information for each `EventId`:
154 +------------------------------------------------+
155 |+------------------------------------------------+
156 ||+------------------------------------------------+
165 +------------------------------------------------+
171 Proposed algorithm is delivered as part of open-source OpenBMC project `[3]`. As
172 this software stack is built with micro-service architecture in mind, the
173 implementation had to be divided into multiple parts:
175 - IPMI Platform Event payload unpacking (`[7]`)
176 - `openbmc/intel-ipmi-oem/src/sensorcommands.cpp`
177 - `openbmc/intel-ipmi-oem/src/ipmi_to_redfish_hooks.cpp`
178 - Intel ME event parsing
179 - `openbmc/intel-ipmi-oem/src/me_to_redfish_hooks.cpp`
180 - Detected events storage (`[4]`)
181 - `systemd journal`
182 - Human-readable message lookup (`[2], [8]`)
183 - `MessageRegistry in bmcweb`
184 - `openbmc/bmcweb/redfish-core/include/registries/openbmc_message_registry.hpp`
190 1. IPMI driver notifies `intel-ipmi-oem` about incoming `Platform Event`
192 - Proper command handler in `intel-ipmi-oem/src/sensorcommands.cpp` is
194 2. Message is forwarded to `intel-ipmi-oem/src/ipmi_to_redfish_hooks.cpp` as
196 - `sel::checkRedfishHooks` analyzes the data, `BIOS` events are handled
197 in-place, while `ME` events are delegated to
198 `intel-ipmi-oem/src/me_to_redfish_hooks.cpp`
201 - `me::utils::storeRedfishEvent(EventId, Parameters)` is called, it stores
207 handler. Implementation of the proposed algorithm is the following:
257 // > call specific handler do determine MessageId and Parameters
269 // in chosen format. Here it stores 2-nd byte in hex format.
294 - `MessageRegistry` - stores all event 'metadata' (severity, resolution notes,
296 - `EventLog` - lists all detected events in the system in processed,
297 human-readable form
301 Implementation of `bmcweb`
304 `openbmc/bmcweb/redfish-core/include/registries/openbmc_message_registry.hpp`.
306 **Intel-specific events have proper prefix in MessageId: either 'BIOS' or
328 System-wide [EventLog](http://redfish.dmtf.org/schemas/v1/LogService.json) is
329 implemented in `bmcweb` at `openbmc/bmcweb/redfish-core/lib/log_services.hpp`.
339 "Created": "1970-01-01T10:22:11+00:00",
352 ….intel.pl/content/www/pl/pl/products/docs/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.ht…
355 …ent logging](https://github.com/openbmc/docs/blob/master/architecture/redfish-logging-in-bmcweb.md)
356 …l.com/content/dam/www/public/us/en/documents/technical-specifications/intel-power-node-manager-v3-…
358 7. [OpenBMC Intel IPMI support](https://github.com/openbmc/intel-ipmi-oem)