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 Li

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>

show more ...

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 Li

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>

show more ...

vpnor: Rename mboxd_pnor_partition_table sources to backend

Change-Id: I6f0fff4ab54e011c1765fc04186e899754787641
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

mboxd: Add backend DBus interface and commandline options

Also implement a backend commandline option to mboxctl: `mboxctl
--backend ...`, to allow easy run-time switching of the backend from the
co

mboxd: Add backend DBus interface and commandline options

Also implement a backend commandline option to mboxctl: `mboxctl
--backend ...`, to allow easy run-time switching of the backend from the
commandline.

Switching between VPNOR and file backends via mboxctl was tested on
Witherspoon, and MTD and file backends on Romulus.

Change-Id: Iaf0e27ecf1d5cdd9e3a31729fb179096bbc37408
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...

mboxd: Remove flash API compatibility shim

The flash API compatibility was kept to reduce the line noise in the
previous backend patch. Remove the compatibility layer now and convert
the remaining c

mboxd: Remove flash API compatibility shim

The flash API compatibility was kept to reduce the line noise in the
previous backend patch. Remove the compatibility layer now and convert
the remaining call-sites.

Change-Id: I4b6e54f4463059a7804918add81e7572db7b7c21
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...

mboxd: Add a backend abstraction layer to mboxd.

Introduce a backend abstraction, enabling multiple implementations to be
compiled in at once. This change formally abstracts the two existing
backend

mboxd: Add a backend abstraction layer to mboxd.

Introduce a backend abstraction, enabling multiple implementations to be
compiled in at once. This change formally abstracts the two existing
backends, mtd and vpnor.

With the backend abstraction in place, subsequent backends are easier to
implement.

This change is based of Evan's work and he retains authorship credit. I
(AJ) have reworked the patch to pass the vpnor tests, refactored some
parts to enable broader use of const structures and others to clarify
the initialisation sequences.

Due to the existing lack of abstraction the patch has unfortunately
wide-ranging impacts. I've whittled it down as much as I consider
reasonable.

Change-Id: I29984a36dae4ea86ec00b853d2a756f0b9afb3ec
Signed-off-by: Evan Lojewski <github@meklort.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...

mboxd: Mark the protocol as reset on shutdown

This is necessary for the host firmware to properly recover from a
daemon restart event, as it needs to re-perform the GET_INFO handshake
and re-establi

mboxd: Mark the protocol as reset on shutdown

This is necessary for the host firmware to properly recover from a
daemon restart event, as it needs to re-perform the GET_INFO handshake
and re-establish any window it had active prior to the daemon
restarting.

While we're here, rename the symbol to align with the documentation.

Change-Id: I628d2ee5972177b7ad78392a86122d16104e7011
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...

mboxd: Refactor and rename mbox.h to mboxd.h

Refine the purpose of the header file to represent what's required for
the daemon itself, not its constituent pieces. Rather, split those
definitions out

mboxd: Refactor and rename mbox.h to mboxd.h

Refine the purpose of the header file to represent what's required for
the daemon itself, not its constituent pieces. Rather, split those
definitions out to their respective header files and include them as
necessary.

Finally the header file is renamed to better reflect its purpose.

Change-Id: I48c409f57d96c844589cd865b24f197477dfe87c
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...