MCTP over PCI on AST2500

Jeremy Kerr jk at
Tue Jan 14 17:20:52 AEDT 2020

Hi Ketan,

Just a suggestion - you probably don't want to be passing MCTP messages over dbus - this is something we learnt from the IPMI implementation.

The current design of the mctp-demux-daemon (included in the libmctp codebase) is intended to provide an interface that will be easy to migrate to a future kernel implementation (ie., using sockets to pass MCTP messages), and allows multiple applications to be listening for MCTP messages of different types.



On 14 January 2020 1:54:49 pm AWST, "Khetan, Sharad" <sharad.khetan at> wrote:
>Hi Deepak,
>On 13/01/20 10:23 PM, Khetan, Sharad wrote:
>> Hi Andrew,
>> On Thu, 9 Jan 2020, at 12:27, Andrew Jeffery wrote:
>>> On Sat, 21 Dec 2019, at 10:45, Khetan, Sharad wrote:
>>>> Hi Andrew,
>>>> Sorry for late response.
>>>> The plan is to have MCTP in user space.
>>> How are you handling this then? mmap()'ing the BAR from sysfs?
>>> Sorry, let me put my brain back in, I was thinking of the wrong side
>of the  BMC/Host MCTP channel. How much were you planning to do in
>userspace on the BMC? As in, are you planning to drive the BMC's PCIe
>MCTP controller from userspace (presumably via /dev/mem)?
>> For implementation on the BMC, we agree that it's better to do it in
>kernel (and as you mentioned  - use consistent interface to upper
>layers, provide another transport). However, given the time needed to
>implement things in kernel (and the review after), we are starting with
>a short term solution. We will be implementing MCTP (protocol elements)
>in user space, along with a low level MCTP PCIe driver just to push
>bits on PCIe. Iwona is working on this and should be able to describe
>the exact primitive.
>Do you plan to do the user-space work as an extension to/reusing
>components from openbmc/libmctp?
>Yes we plan to reuse and extend the libmctp, support PCIe as well as
>SMBus bindings. We plan to use d-bus extensions to existing libmctp.
>That said, we will know the exact extent of reuse/modifications when we
>really start implementing.
>We are implementing this for AST 2600 (will not support any workarounds
>for AST 2500 bug). 
>@Andrew, Thanks for your response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openbmc mailing list