| commit | e50e654bca8df8254c15849c793f9279adcb1182 | [log] [tgz] |
|---|---|---|
| author | Stewart Smith <stewart@linux.ibm.com> | Mon Nov 19 13:49:46 2018 +1100 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Tue Mar 26 16:31:22 2019 +1030 |
| tree | 8e6c1adf7f96b217026e86625a2362f712a143a2 | |
| parent | 4519bb82624e8a80905b2914334edd27fbe61029 [diff] |
Add --trace support (in blktrace format) In an effort understand what PNOR requests come from the host, it'd be good to be able to trace what requests come in and visualise them. blktrace is some Linux infrastructure for tracing block device activity all the way through the linux block layer, for which there is a variety of existing tooling. These tools process the (typically) kernel produced blktrace output. We can produce this same output programatically from mboxd though. This patch gives us the (option) to start mboxd in a mode where it will write a blktrace file out, which can be fed into tools like blkparse(1) or tools like iowatcher[1] to generate charts (and video). A quirk of the blktrace format is that it's very geared towards a full IO subsystem, so we can't directly map window operations (what we know in mboxd) to specific IO ops (i.e. we don't get "firmware read one page out of this window before closing it"). So, for each Window opening (or reusing a cached one), we write THREE blktrace events: a Queue, Dispatch, and Complete. We can usk tools like blkparse to do everything from get a detailed list of what windows were opened and for how long: 0,0 0 1 0.000000000 0 Q R 0 + 8 [(null)] 0,0 0 2 0.000000000 0 D R 0 + 8 [(null)] 0,0 0 3 0.000182022 0 C R 0 + 8 [0] 0,0 0 4 0.042416351 0 Q R 4144 + 2040 [(null)] 0,0 0 5 0.042416351 0 D R 4144 + 2040 [(null)] 0,0 0 6 0.060802662 0 C R 4144 + 2040 [0] 0,0 0 7 0.084775813 0 Q R 64 + 288 [(null)] 0,0 0 8 0.084775813 0 D R 64 + 288 [(null)] 0,0 0 9 0.087835720 0 C R 64 + 288 [0] 0,0 0 10 1.429234244 0 Q R 8488 + 2048 [(null)] to getting a simple summary at the end of how many windows were opened read and read/write: CPU0 (0,0): Reads Queued: 90, 74,040KiB Writes Queued: 6, 2,664KiB Read Dispatches: 90, 74,040KiB Write Dispatches: 6, 2,664KiB Reads Requeued: 0 Writes Requeued: 0 Reads Completed: 90, 74,040KiB Writes Completed: 6, 2,664KiB Read Merges: 0, 0KiB Write Merges: 0, 0KiB Read depth: 1 Write depth: 1 IO unplugs: 0 Timer unplugs: 0 If you change the window size to something tiny, like 4096 bytes, you can get detailed paging information for hostboot at the expense of IPL time. Pretty graphs and animations: https://www.flamingspork.com/blog/?p=4419 [1] iowatcher: http://masoncoding.com/iowatcher/ Change-Id: I5dd02b6bc616c441abf54d87a5d67c972cbaf228 Signed-off-by: Stewart Smith <stewart@linux.ibm.com> [AJ: Resolve merge conflicts, some tidy ups] Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Copyright 2017 IBM
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
This repo contains the protocol definition for the host to BMC mailbox communication specification which can be found in Documentation/mbox_procotol.md.
There is also a reference implementation of a BMC mailbox daemon, the details of which can be found in Documentation/mboxd.md.
Finally there is also an implementation of a mailbox daemon control program, the details of which can be found in Documentation/mboxctl.md.
The build system is a standard autotools setup. bootstrap.sh runs all the jobs necessary to initialise autotools.
By default mboxd is configured and built without the 'virtual PNOR' feature discussed below. The virtual PNOR functionality is written in C++, and due to some autotools clunkiness even if it is disabled mboxd will still be linked with CXX. Point CXX to cc at configure time if you do not have a C++ compiler for your target (./configure CXX=cc).
If you are hacking on the reference implementation it's recommended to run bootstrap.sh with the dev argument:
$ ./bootstrap.sh dev $ ./configure $ make $ make check
This will turn on several of the compiler's sanitizers to help find bad memory management and undefined behaviour in the code via the test suites.
Otherwise, build with:
$ ./bootstrap.sh $ ./configure $ make $ make check
In addition to its role as a flash abstraction mboxd can also serve as a partition/filesystem abstraction. This feature is known as 'virtual PNOR' and it can be enabled at configure time (note that this requires a C++ compiler for your target):
$ ./bootstrap.sh $ ./configure --enable-virtual-pnor $ make $ make check
This codebase is a mix of C (due to its heritage) and C++. This is an ugly split: message logging and error handling can be vastly different inside the same codebase. The aim is to remove the split one way or the other over time and have consistent approaches to solving problems.
phosphor-mboxd is developed as part of the OpenBMC project, which also leads to integration of frameworks such as phosphor-logging. Specifically on phosphor-logging, it's noted that without care we can achieve absurd duplication or irritating splits in where errors are reported, as the C code is not capable of making use of the interfaces provided.
Message logging MUST be done to stdout or stderr, and MUST NOT be done directly via journal APIs or wrappers of the journal APIs.
Rationale:
We have two scenarios where we care about output, with the important restriction that the method must be consistent between C and C++:
In the first case it is desirable that the messages appear in the system journal. To this end, systemd will by default capture stdout and stderr of the launched binary and redirect it to the journal.
In the second case it is desirable that messages be captured by the test runner (make check) for test failure analysis, and it is undesirable for messages to appear in the system journal (as these are tests, not issues affecting the health of the system they are being executed on).
Therefore direct calls to the journal MUST be avoided for the purpose of message logging.
Note: This section specifically targets the use of phosphor-logging's log<T>(). It does not prevent the use of elog<T>().