1. 04 Sep, 2019 4 commits
  2. 03 Sep, 2019 3 commits
  3. 07 Aug, 2019 1 commit
  4. 20 Jun, 2019 1 commit
    • Andrew Jeffery's avatar
      mboxd: Don't require mbox · 4b8203d7
      Andrew Jeffery authored
      With the DBus interface to the daemon in place it's possible to
      implement any hardware interface in terms of the DBus interface. This is
      the strategy used to support the IPMI HIOMAP transport. Further, the use
      of MBOX is deprecated due to security concerns. We want to drop the
      driver from the kernel, which failed to get traction upstream, so make
      support optional.
      
      As a consequence, switch the default transport to DBus.
      
      Change-Id: I9f16ca053ce48943dce59b83ca991ec5494580d8
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      4b8203d7
  5. 17 May, 2019 1 commit
    • Andrew Jeffery's avatar
      dbus: Unref replies to avoid leaks · fac3689e
      Andrew Jeffery authored
      Testing showed that failing to free DBus message replies was leaking
      800-900kiB per boot. After adding the appropriate unrefs, mboxd memory
      consumption stayed stable at 71920kiB across multiple reboots of the
      host.
      
      The root cause was identified using a DBus capture of the host's IPMI
      traffic during boot, then reducing the output to mboxd-specific messages
      and turning them into commands that could be run with ipmitool. Adding
      all of these commands to a script and running `pmap` between ipmitool
      invocations showed the growth in memory usage across the "boot" process,
      but this did not correlate with any particular set of commands to mboxd.
      The lack of correlation lead to the hypothesis that we might be able to
      reproduce by sending a lot of dbus messages, such as:
      
      ```
      root@witherspoon:/tmp# for i in `seq 1 10000`; do \
      busctl call xyz.openbmc_project.Hiomapd \
      	/xyz/openbmc_project/Hiomapd \
      	xyz.openbmc_project.Hiomapd.Protocol.V2 \
      	GetInfo y 2; \
      done
      ```
      
      Spamming the daemon in this way demonstrated the growth in memory seen
      during a regular boot process, confirming that just sending DBus
      messages was enough.
      
      Add the necessary unrefs for the replies at the end of each method
      handler to ensure the replies are appropriately freed.
      
      Testing and confirmation of the fix were performed on a Witherspoon
      system.
      
      Change-Id: If5fe7576aaca1be617181526bf64511ccee1dd9f
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      fac3689e
  6. 05 Apr, 2019 2 commits
  7. 02 Apr, 2019 1 commit
  8. 31 Mar, 2019 1 commit
  9. 29 Mar, 2019 1 commit
    • Stewart Smith's avatar
      Add --trace support (in blktrace format) · ef0c8360
      Stewart Smith authored
      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: default avatarStewart Smith <stewart@linux.ibm.com>
      [AJ: Resolve merge conflicts, some tidy ups]
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      ef0c8360
  10. 26 Mar, 2019 1 commit
    • Stewart Smith's avatar
      Add --trace support (in blktrace format) · e50e654b
      Stewart Smith authored
      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: default avatarStewart Smith <stewart@linux.ibm.com>
      [AJ: Resolve merge conflicts, some tidy ups]
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      e50e654b
  11. 20 Mar, 2019 1 commit
  12. 19 Mar, 2019 9 commits
  13. 18 Mar, 2019 6 commits
    • Evan Lojewski's avatar
      mboxd: Add support for file-backed flash devices. · a042978b
      Evan Lojewski authored
      This commit adds a new file based backing source.  The file based
      backing source takes a raw pnor image that is usually flashed to a mtd
      device.
      
      This backing source enabled rapid testing of pnor images.
      
      Tested on Witherspoon with the VPNOR and file backends, and Romulus for
      the MTD and file backends.
      
      Change-Id: I253ecfa6b58d071c7982f153ad50da8e4ad39fa2
      Signed-off-by: default avatarEvan Lojewski <github@meklort.com>
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      a042978b
    • Andrew Jeffery's avatar
      mboxd: Remove flash API compatibility shim · 0297e5b8
      Andrew Jeffery authored
      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's avatarAndrew Jeffery <andrew@aj.id.au>
      0297e5b8
    • Evan Lojewski's avatar
      mboxd: Add a backend abstraction layer to mboxd. · f1e547c7
      Evan Lojewski authored
      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: default avatarEvan Lojewski <github@meklort.com>
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      f1e547c7
    • Andrew Jeffery's avatar
      flash: Introduce flash_validate() · cb93504e
      Andrew Jeffery authored
      Clean up the protocol_negotiate_version() mess. The existing approach
      came about due to viewing the vpnor implementation as an edge case in
      its own right. The code becomes much neater if we consider all backends
      as equal and afford them the callbacks necessary for correct behaviour.
      
      Change-Id: Ifaeee9da459818cf22b2f137ddc5b8d0356b9be9
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      cb93504e
    • Andrew Jeffery's avatar
      protocol: Introduce protocol_reset() · f69760da
      Andrew Jeffery authored
      protocol_reset() encapsulates the actions necessary to return the LPC
      state to what's required to boot the host. This is backend dependent;
      for the mtd backend we can simply point the bridge at the host flash
      AHB mapping, and for the virtual pnor we want to rearrange the content
      of the LPC reserved memory (leaving the bridge pointed there). In either
      case the state of the FWH address space is distured, so inform the host
      as necessary.
      
      Change-Id: Ie8efd1f703a3616c33f76f4e735c1efea039146c
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      f69760da
    • Andrew Jeffery's avatar
      vpnor: Test if HBB placement exceeds reserved memory bounds · 4e75a27a
      Andrew Jeffery authored
      If a host firmware image is provided where the placement of HBB exceeds
      the reserved memory size then an out-of-bounds write would occur.
      
      Change-Id: I0a98cb7417511cc8dd5bd2e12c9232ebc912dcd6
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      4e75a27a
  14. 15 Mar, 2019 4 commits
  15. 14 Feb, 2019 1 commit
  16. 13 Feb, 2019 1 commit
  17. 08 Jan, 2019 2 commits
    • Andrew Jeffery's avatar
      transport: dbus: Remove ProtocolReset and WindowReset signals · 9ed627ca
      Andrew Jeffery authored
      These are replaced by the equivalent properties.
      
      Change-Id: Ie2acb98cc592c0ed1f2039f8aa570f1c7944b1e2
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      9ed627ca
    • Andrew Jeffery's avatar
      vpnor: Enforce a read-only FFS ToC regardless of flags · 7a85d22a
      Andrew Jeffery authored
      The virtual PNOR implementation never properly honoured writes to the
      FFS ToC, as the ToC's binary representation is generated from the CSV
      file shipped in the PNOR squashfs image.
      
      What *did* happen was that opening a write window to the ToC region
      succeeded and writes could be flushed, but the flushed writes were never
      read, and ToC representation internal to mboxd was never updated to
      match the written state. Thus the written values "persisted" until the
      ToC's window fell out of the cache (with 64MiB reserved regions,
      probably on a host reboot).
      
      Short circuit the insanity of handling FFS more than we have to by
      forcefully marking the ToC as read-only, regardless of the flag
      configuration shipped in the CSV representation. This prevents the host
      from successfully opening a write window and thus the host can have no
      expectation of write persistence.
      
      Change-Id: Ib2788c56b245da506cb7d607c0758b17785766cf
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      7a85d22a