MCTP over PCI on AST2500

Thomaiyar, Richard Marian richard.marian.thomaiyar at
Wed Jan 15 02:54:16 AEDT 2020

Yes Jeremy. We are aware about the limitation, but as Sharad stated, we 
will be starting with D-Bus based approach, due to priority ( and then 
move to socket based approach, at-least not immediately).

Having said that pushed a WIP document for both MCTP & PLDM (still in 
high level, and low level implementation details capturing are in 
progress). We can further discuss in the review (for better tracking).



Note: Proposal is to have a abstraction layer between D-Bus & Socket, so 
that upper layers like PLDM can switch to socket-driver based approach 
at later stage.

Related to MCTP over PCIe Iowna will send out a review which will be 
along the MCTP base design document.



On 1/14/2020 12:09 PM, Khetan, Sharad wrote:
> Thanks for the pointer Jeremy. We will look into demux daemon.
> Thanks,
> -Sharad
> On Jan 13, 2020, at 10:21 PM, Jeremy Kerr <jk at 
> <mailto:jk at>> wrote:
>> 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.
>> Regards,
>> Jeremy
>> On 14 January 2020 1:54:49 pm AWST, "Khetan, Sharad" 
>> <sharad.khetan at <mailto: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?
>>     Thanks,
>>     Deepak
>>     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.
>>     Thanks,
>>     Sharad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openbmc mailing list