Re: An in-kernel implementation of MCTP for a socket-based interface to MCTP networks

[Andrew Jeffery]

On Sat, 8 Jun 2019, at 05:14, Supreeth Venkatesh wrote:
> On Thu, 2019-05-30 at 17:34 +0930, Andrew Jeffery wrote:
> > 
> > The DMTF PCMI WG have defined various bindings for MCTP, including
> > PCIe VDM,
> > KCS, serial and SMBus/I2C.
> > 
> > Putting my OpenPOWER hat on, we were looking at what bindings we
> > could make use
> > of in our platform designs. We make heavy use of the LPC bus during
> > early boot,
> > and so solutions needed to be useful across that interface. This
> > requirement
> > eliminates PCIe VDM (as do constraints in our PHBs). There's also no
> > path for
> > SMBus/I2C, leaving KCS and serial. KCS as it stands is pretty much
> > MCTP wrapped
> > in IPMI across a slow interface, and serial's no speed demon either.
> > Additionally, we can only use the VUART, and there's only one in the
> > AST2400/AST2500, so if we were to use it we'd have to multiplex the
> > console
> > with MCTP messages. This is all fairly ugly.
> > 
> > What Jeremy has proposed is a yet-to-be-standardised LPC MCTP binding
> > that
> > makes use of both a portion of the LPC FW space and a KCS device in
> > the LPC IO
> > space. This is made possible on ASPEED hardware by pointing the
> > LPC2AHB bridge
> > at a region of RAM, and defining an ABI for Rx and Tx buffers within
> > that
> > memory region. The KCS interface is then lightly used as an out-of-
> > band
> > mechanism for arbitration of buffer ownership. This gets us an
> > efficient
> > LPC-based interface for MCTP on our platforms that is compatible with
> > existing
> > hardware.
> Can LPC binding be proposed to DMTF PMCI group for standardization. I
> heard it briefly mentioned by Deepak in one of the calls, but dont
> think we have a document ready yet. Correct?

Correct. Currently we're considering it a bit OpenPOWER-specific. Once we've
got a better grip on it we can consider proposing it to PMCI for standardisation.

> > 
> > What it needs
> > -------------
> > 
> > There roughly four areas of work that fall out of the idea:
> > 
> > 1. Doing the work to expose AF_MCTP from the kernel with support for
> > SOCK_RAW
> >    (exposing raw MCTP packets) and SOCK_DGRAM (fully assembled MCTP
> > messages).
> > 2. Exposing an out-of-band management interface to describe MCTP
> > networks to
> >    the kernel. The plan is to do this via the kernel's netlink
> > interface.
> Not sure by what you mean by out of band interface here. MCTP is meant
> to be used for "inside the box" communication. Can you please
> elaborate?

"Out-of-band" in this context simply meant "not using the MCTP socket":
BMC userspace will talk via a (separate) netlink socket to the kernel to
provide the kernel with the MCTP network topology information it needs
to instantiate MCTP interfaces, bridges and networks, and to route MCTP
packets across interfaces. ("Out-of-band" was not meant e.g. as a contrast
to "In-band IPMI", where communication happens external to the platform).

Hope that helps.

Andrew