Unfork phosphor-mboxd from mboxbridge

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

mboxd_windows: Shrink windows accessing the end of flash

The host may request a window over the end of the flash where the window
size combined with the requested offset exceeds the limi

mboxd_windows: Shrink windows accessing the end of flash

The host may request a window over the end of the flash where the window
size combined with the requested offset exceeds the limit of the flash.
This issue was introduced with the virtual PNOR, as copy_flash() now may
return a size less than requested. This leads to offset requests that
are still block aligned, but the windows may no longer be aligned with
respect to the flash size.

This issue triggers the read error reported from the Petitboot
environment in an earlier commit message:

/ # cat /dev/mtd0 > /dev/null
[ 501.061616288,3] MBOX-FLASH: Bad response code from BMC 2
[ 501.150405995,3] MBOX-FLASH: Error waiting for BMC
cat: read error: Input/output error
/ # echo $?
1
/ #

With the corresponding mboxd trace on the BMC:

[ 1519966031.652036815] Received MBOX command: 4
[ 1519966031.652272613] Host requested flash @ 0x03f1a000
[ 1519966031.652411603] Tried to open read window past flash limit
[ 1519966031.652500088] Couldn't create window mapping for offset 0x03f1a000
[ 1519966031.652607966] Error handling mbox cmd: 4
[ 1519966031.652661421] Writing MBOX response: 2
[ 1519966031.652762229] Error handling MBOX event

Instead, shrink the request such that the resulting window exactly maps
the flash limit, and no further.

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

show more ...

mboxd_windows: Reset evicted windows

After copying a portion of the backing store to a window,
create_map_window() "resizes" the window to the aligned-up size reported
by copy_flash(

mboxd_windows: Reset evicted windows

After copying a portion of the backing store to a window,
create_map_window() "resizes" the window to the aligned-up size reported
by copy_flash(). This allows use of the window size as the content size
elsewhere in the codebase.

However, if we needed to evict a window to satisfy a request, the window
properties were not reset. This lead to inefficient use of the reserved
memory by limiting the effective window size to the minimum size of all
requests that were previously allocated the window in question.

Inefficient use of reserved memory isn't the only side effect; the host
takes an eye-watering hit to throughput that gets exponentionally
worse over time:

From the petitboot shell without the patch applied:

/ # time cat /dev/mtd0 > /dev/null
real 0m 49.77s
user 0m 0.00s
sys 0m 49.76s
/ # time cat /dev/mtd0 > /dev/null
real 1m 33.57s
user 0m 0.00s
sys 1m 33.55s
/ # time cat /dev/mtd0 > /dev/null
real 4m 45.37s
user 0m 0.00s
sys 4m 45.35s
/ # time cat /dev/mtd0 > /dev/null
real 9m 17.77s
user 0m 0.00s
sys 9m 17.76s
/ #

And with the patch applied:

/ # time cat /dev/mtd0 > /dev/null
real 0m 43.00s
user 0m 0.00s
sys 0m 42.99s
/ # time cat /dev/mtd0 > /dev/null
real 0m 42.40s
user 0m 0.00s
sys 0m 42.39s
/ # time cat /dev/mtd0 > /dev/null
real 0m 42.41s
user 0m 0.00s
sys 0m 42.39s
/ #

Reset the properties to allow use of the entire reserved memory region
allocated to the window, improving memory efficiency, throughput, and
minimising throughput variance.

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

show more ...

pnor_partition: Handle requests exceeding partition's actual size

Partitions with patch files whose size was less than the partition size
in the ToC could not be completely read by the h

pnor_partition: Handle requests exceeding partition's actual size

Partitions with patch files whose size was less than the partition size
in the ToC could not be completely read by the host. For example when
scanning over the entire PNOR on the host with `cat /dev/mtd0 >
/dev/null` the host would lock up. A trace from mboxd under these
circumstances shows:

[ 1519832857.966501396] Received MBOX command: 4
[ 1519832857.966695620] Host requested flash @ 0x02a44000
[ 1519832857.968642020] Window @ 0x730ce000 for size 0x00024000 maps flash offset 0x02a44000
[ 1519832857.968808728] Writing MBOX response: 1
[ 1519832858.222090630] Received MBOX command: 4
[ 1519832858.222284692] Host requested flash @ 0x02a68000
[ 1519832858.223964544] Window @ 0x73cce000 for size 0x00009000 maps flash offset 0x02a68000
[ 1519832858.224136142] Writing MBOX response: 1
[ 1519832858.435944292] Received MBOX command: 4
[ 1519832858.436138394] Host requested flash @ 0x02a71000
[ 1519832858.437026725] Window @ 0x734ce000 for size 0x00007000 maps flash offset 0x02a71000
[ 1519832858.437195251] Writing MBOX response: 1
[ 1519832858.646768070] Received MBOX command: 4
[ 1519832858.646968637] Host requested flash @ 0x02a78000
[ 1519832858.647567228] Window @ 0x768ce000 for size 0x00001000 maps flash offset 0x02a78000
[ 1519832858.647731755] Writing MBOX response: 1
[ 1519832858.848288015] Received MBOX command: 4
[ 1519832858.848489188] Host requested flash @ 0x02a79000
[ 1519832858.849006404] Window @ 0x758ce000 for size 0x00000000 maps flash offset 0x02a79000
[ 1519832858.849168870] Writing MBOX response: 1
[ 1519832859.048631708] Received MBOX command: 4
[ 1519832859.048827305] Host requested flash @ 0x02a79000
[ 1519832859.049343956] Window @ 0x756ce000 for size 0x00000000 maps flash offset 0x02a79000
[ 1519832859.049503553] Writing MBOX response: 1
[ 1519832859.248950916] Received MBOX command: 4
[ 1519832859.249142069] Host requested flash @ 0x02a79000
[ 1519832859.249649871] Window @ 0x741ce000 for size 0x00000000 maps flash offset 0x02a79000

Of significance are the last three CREATE_READ_WINDOW requests, where
the request succeeds but mboxd reports back a zero-sized window to the
host. The host immediately considers itself done with the window, and
requests a new window offset from the previous by size, which is zero.
Thus it re-requests the same offset, and receives the same zero-sized
window in return.

As a result, firmware gets stuck in an unterminated loop, stealing the
core from Linux, which promptly starts reporting a constant stream of
RCU stall warnings among the rest of the failures. Everyone is
miserable.

The offset in question maps to a partition but not to a valid offset in
the file backing that partition. Resize the backing file to meet the
maximum access address within the limits of the partition size defined
in the ToC. By doing so, we are able to map as much of the partition as
necessary.

However, we're not done. Whilst we no longer crash the host, we still
don't successfully complete the operation the host requested. From
Petitboot:

/ # cat /dev/mtd0 > /dev/null
[ 501.061616288,3] MBOX-FLASH: Bad response code from BMC 2
[ 501.150405995,3] MBOX-FLASH: Error waiting for BMC
cat: read error: Input/output error
/ # echo $?
1
/ #

And the corresponding mboxd trace on the BMC:

[ 1519966031.652036815] Received MBOX command: 4
[ 1519966031.652272613] Host requested flash @ 0x03f1a000
[ 1519966031.652411603] Tried to open read window past flash limit
[ 1519966031.652500088] Couldn't create window mapping for offset 0x03f1a000
[ 1519966031.652607966] Error handling mbox cmd: 4
[ 1519966031.652661421] Writing MBOX response: 2
[ 1519966031.652762229] Error handling MBOX event

The read failure will be fixed in a follow-up patch.

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

show more ...

misc: Replace license blurb with kernel-style SPDX markers

This was roughly achieved by the following shell script:

$ git ls-files |
grep '\.[ch]p*$' |
while

misc: Replace license blurb with kernel-style SPDX markers

This was roughly achieved by the following shell script:

$ git ls-files |
grep '\.[ch]p*$' |
while read F; do EXT=${F##*.}; cat spdx.$EXT <(sed '/^\/\*$/,/^ \*\/$/d' $F) > ${F}.tmp; mv ${F}.tmp $F; done

With the following context:

$ cat spdx.c
// SPDX-License-Identifier: Apache-2.0
// Copyright (C) 2018 IBM Corp.
$ cat spdx.h
/* SPDX-License-Identifier: Apache-2.0 */
/* Copyright (C) 2018 IBM Corp. */
$ ls -l spdx.*
-rw-r--r-- 1 andrew andrew 71 Feb 27 12:02 spdx.c
lrwxrwxrwx 1 andrew andrew 6 Feb 27 12:02 spdx.cpp -> spdx.c
-rw-r--r-- 1 andrew andrew 77 Feb 27 12:02 spdx.h
lrwxrwxrwx 1 andrew andrew 6 Feb 27 12:02 spdx.hpp -> spdx.h

The `sed` invocation catches a lot of function documentation, so the
hunks were manually added to avoid removing information that we want to
keep.

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

show more ...

vpnor: Fix unable to read unaligned partition override files

Currently when using vpnor and an override file is applied which has
an unaligned size it is impossible to read the last unal

vpnor: Fix unable to read unaligned partition override files

Currently when using vpnor and an override file is applied which has
an unaligned size it is impossible to read the last unaligned bit of
the file. This is because the response to the host truncates the window
size when converting from bytes to blocks (effectively aligning down
the size and causing the window to look smaller than it is).

We could blindly align up the size but then the host would be within
its rights to access uninitialised memory which we would like to avoid.
To work around this we always align the window size up to a multiple
of block size. Any memory not read from the file is set to 0xFF to
mimic erased flash.

Fixes: https://github.com/openbmc/openbmc/issues/2344

Reported-by: Stewart Smith <sesmith@au1.ibm.com>
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: Ic857c31e9402b98ab19dba1a23adc74eaf40491b

show more ...

vpnor: correct offset alignment

With the current implementation of the virtual pnor, a window contains
at most one partition, and a partition may be smaller than the window
max size.

vpnor: correct offset alignment

With the current implementation of the virtual pnor, a window contains
at most one partition, and a partition may be smaller than the window
max size. An offset requested by the host, which starts right after such
a small partition ends, must result in a new window mapping (because
said offset points to another partition).

Change-Id: I07fd51c6af2c8125891073bf10ceb1399a55dc92
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>

show more ...

copy_flash: update window size

When a pnor partition is copied to a window, update the window size with
the actual number of blocks copied. This is required in the response of
the V2

copy_flash: update window size

When a pnor partition is copied to a window, update the window size with
the actual number of blocks copied. This is required in the response of
the V2 Read Window Command.

Change-Id: I2c158df1bd261a4e62b9cbb2765e7623a7fb3dc9
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>

show more ...

mboxd: Introduce a new DEBUG log level

Currently there is no output on the console unless -v is specified on
the command line which enables error output. A second -v will provide
inf

mboxd: Introduce a new DEBUG log level

Currently there is no output on the console unless -v is specified on
the command line which enables error output. A second -v will provide
info output.

We probably want error output irrespective of whether a -v was given
on the command line because people generally want to know why their
program stopped working.

Make error output unconditional.

A single -v will give minimal informational output which is a good
level to see what the daemon is doing without barfing all over the
console.

A second -v will enable debug output which will print highly verbose
information which will be useful for debugging. Probably don't enable
this under normal circumstances.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I3da25f7e4e9e976c17389fcceb1d85ef98de7e0a

show more ...

mboxd: Implement timeout return value in GET_MBOX_INFO

The previous patch added a new return field in GET_MBOX_INFO called
"suggested timeout" to be used to provide a suggested maximum t

mboxd: Implement timeout return value in GET_MBOX_INFO

The previous patch added a new return field in GET_MBOX_INFO called
"suggested timeout" to be used to provide a suggested maximum timeout
value to the host.

Add this to the return arguments of GET_MBOX_INFO.

Note that the host is free to ignore the value and the daemon can
leave this blank if it doesn't want to provide a timeout.

We hard code a milliseconds per megabyte value which was determined
to be approximately 8000 based on testing and is close to linear
as the access size changes. Testing was conducted on an Aspeed ast2500
on a Witherspoon with the dev-4.7 OpenBMC branch.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: If24e41ebb1d9f03c2bdcca84819f9430fd3eeff6

show more ...

mboxd: Make window size and number optional command line parameters

The window size and number command line parameters are used to control
the number of windows and the size of each of t

mboxd: Make window size and number optional command line parameters

The window size and number command line parameters are used to control
the number of windows and the size of each of the windows in the window
cache which the reserved memory region is divided between.

Most people won't care about tuning these or just won't know what they
refer to. Additionally in the event we change how the window cache
works or allow a non-constant window size then the meaning of these
becomes unclear.

Daemon implementations may also choose to just not implement a cache so
making these required parameters may hurt portability.

Make the window size and number command line parameters optional rather
than required so that they can be largly ignored while people who really
care about tuning them can still do so.

The default for now is to have windows of size 1MB and to map the entire
reserved memory region. That is:
number of windows = size of memory region / size of windows

This means that the size of the reserved memory region can be reduced
and the daemon will adapt to this.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I7c7bbef6e5d31d1372ec3a755877cacc6c135cce

show more ...

mboxd: Update mboxd to implement protocol V2 and add dbus support

Version 2 of the mbox protocol contains a few changes such as:
- All sizes are in block size
- Adds an erase comma

mboxd: Update mboxd to implement protocol V2 and add dbus support

Version 2 of the mbox protocol contains a few changes such as:
- All sizes are in block size
- Adds an erase command
- Adds new response codes
- Adds new BMC events
- Open windows commands now take a size directive

Update the mailbox daemon to support version 2 of the protocol which
includes implementing all of the V2 functionality. Also entirely refactor
the mboxd.c code to make it more modular improving readability and
maintainability.

At the same time improve the functionality by adding:
- Multiple windows in the daemon (still only one active window) to cache
flash contents
- Implement a dbus interface to allow interaction with the daemon
- Handle sigterm and sigint and terminate cleanly

The previous implementation utilised the entire reserved memory region.
Update the daemon so that on the command line the number of windows and
the size of each which the reserved memory region will be split into can
be specified. The reserved memory region is then divided between the
windows, however there can still only be one "active" window at a time.
The daemon uses these windows to cache the flash contents meaning the
flash doesn't have to be copied when the host requests access assuming
the daemon already has a copy.

A dbus interface is added so that commands can be sent to the daemon to
control it's operation from the bmc. These include suspending and resuming
the daemon to synchronise flash access, telling the daemon to point the lpc
mapping back to flash and telling the daemon when the flash has been
modified out from under it.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I10be01a395c2bec437cf2c825fdd144580b60dbc

show more ...