1. 15 Mar, 2019 1 commit
    • Andrew Jeffery's avatar
      vpnor: Shuffle and rework includes for sanity · 261f61a1
      Andrew Jeffery authored
      Include ordering and whether or not C linkage is forced by `extern "C"`
      blocks can cause headaches at link time. Ensure that all C dependencies
      are included in an `extern C` block before other includes occur. Also
      include the C++ versions of string.h and assert.h
      
      Change-Id: Ia96f6044d40c8eccb907b65924efcf62ac7a89c3
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      261f61a1
  2. 14 Feb, 2019 1 commit
  3. 13 Feb, 2019 1 commit
  4. 08 Jan, 2019 4 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
    • Andrew Jeffery's avatar
      vpnor: test: Add force_readonly_toc · 8a0efd5e
      Andrew Jeffery authored
      This ensures that the ToC presented to the host indicates that it is not
      writable. The virtual PNOR implementation has never properly honoured
      writes to the ToC, so lets at least tell the host.
      
      As the code has not yet been fixed to implement the desired behaviour,
      add the test to XFAIL_TESTS.
      
      Change-Id: Ia13a0f907f916d6dec3979b17685d54bc578a106
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      8a0efd5e
    • Andrew Jeffery's avatar
      vpnor: Add write-to-writable-ToC test · 89985754
      Andrew Jeffery authored
      Tests if mutations survive re-opening the window. They don't, so add the
      test to XFAIL_TESTS.
      
      Change-Id: Ic2f844c30a7da35033bf03012ea452718d2843e4
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      89985754
  5. 17 Dec, 2018 1 commit
  6. 26 Nov, 2018 1 commit
    • Andrew Jeffery's avatar
      protocol: Rework publication of events over DBus transport · fd4fa34d
      Andrew Jeffery authored
      A set of races was discovered around the propagation of HIOMAP protocol
      BMC status events during BMC shutdown. In particular the change impacts
      the design of the DBus transport defined in the protocol specification,
      as signalling of both acknowledgeable and non-acknowledgeable events
      could not be made atomic.
      
      A particular case where this matters is when the daemon is terminated,
      at which point it should simultaneously clear BMC_EVENT_DAEMON_READY and
      set BMC_EVENT_PROTOCOL_RESET. The DBus interface as designed required
      this be done as two separate messages, which lead to races propagating
      the complete state update to the host during shutdown of ipmid.
      
      Change-Id: Iaf38f77c28b8e4e4dd092b0de97dc7e777bfac65
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      fd4fa34d
  7. 08 Nov, 2018 1 commit
  8. 07 Nov, 2018 3 commits
    • Andrew Jeffery's avatar
      mboxd: Mark the protocol as reset on shutdown · fab672bd
      Andrew Jeffery authored
      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's avatarAndrew Jeffery <andrew@aj.id.au>
      fab672bd
    • Andrew Jeffery's avatar
      mboxd: Broadcast the daemon is ready on all transports · fe0c9e86
      Andrew Jeffery authored
      The code as it stood only sent the state update at startup on the active
      transport, which is somewhat arbitrarily chosen as an implementation
      detail of the mbox initialisation function.
      
      If the host firmware is using IPMI, it will not learn of the update
      unless it attempts to contact mboxd, which it won't do if it knows the
      daemon isn't there, which it may have learned of by receiving a state
      update from the daemon's shutdown path. In this circumstance the host
      firmware is now stuck.
      
      Relieve the host firmware of this problem by always sending the daemon
      state on all supported transports. To avoid some insanity we introduce a
      new callback in struct transport_ops that allows use to send the BMC's
      entire event state rather than just set or clear updates.
      
      Change-Id: I094ff4089eeebd8be99fbd343b94f7bbef023fb1
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      fe0c9e86
    • Andrew Jeffery's avatar
      transport: Fix event handling · f62601b8
      Andrew Jeffery authored
      Events were not quite being handled as per the intent of the recent
      refactor: The protocol layer was meant to record the raw set of events
      and provide the protocol-version-specific mask to the transport layer,
      which the transport layer would then use to flush out the state in
      accordance with its implementation-specific requirements.
      
      What was going wrong was that the transport implementations were
      overwriting the raw set of events with the protocol-specific masked set
      of events, meaning that we'd lose the raw state and provide an
      incomplete BMC state value on protocol upgrade.
      
      Rework the event handling to make sure the responsibilities are properly
      split between the layers.
      
      Change-Id: Iace6615a121e4ce7dcca690d9adf62e5ab9ccee2
      Signed-off-by: Andrew Jeffery's avatarAndrew Jeffery <andrew@aj.id.au>
      f62601b8
  9. 01 Nov, 2018 1 commit
  10. 12 Oct, 2018 3 commits
  11. 14 Sep, 2018 20 commits
  12. 12 Sep, 2018 3 commits