From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 82C487803D1 for ; Thu, 28 Sep 2023 18:18:14 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=GlfONEAdFjcXY+GoAd4uVD+4KWgSJ1U584yK0BsyJxs=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1695925093; v=1; b=kUFF/3kLyVyoxpUIDoHHW1BsiGWM+Qf9SdycmkajU1Fd/q9AEQnDP5Xf3EGFLQQb6NErqnqr UcyNeX2bCYy4bpKE6JLNWEm3cfPSF9zD2+RiJR3UpSt4WnzLbgkYyBt3cosc/I5zW8OhZzUMbIl pF9gvUYIr6EXBK0cdLY1E++U= X-Received: by 127.0.0.2 with SMTP id n0NuYY7687511xIEMbjjJWt3; Thu, 28 Sep 2023 11:18:13 -0700 X-Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by mx.groups.io with SMTP id smtpd.web11.115.1695925092144327068 for ; Thu, 28 Sep 2023 11:18:12 -0700 X-Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-7b07548b084so356681241.1; Thu, 28 Sep 2023 11:18:12 -0700 (PDT) X-Gm-Message-State: far9xnHmX8eBNht5tFP4i4AYx7686176AA= X-Google-Smtp-Source: AGHT+IFwVS2oQj7u6YWMNYWoKTUAv7YMCBqrGForeNGyAPQVG7Vu0qmx552KYUZpVETiaDbFi80LapYTsua+m6WKsPA= X-Received: by 2002:a05:6102:14a:b0:452:5dbd:bd4d with SMTP id a10-20020a056102014a00b004525dbdbd4dmr1796562vsr.17.1695925090861; Thu, 28 Sep 2023 11:18:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Konstantin Aladyshev" Date: Thu, 28 Sep 2023 21:17:59 +0300 Message-ID: Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS To: "Chang, Abner" Cc: "devel@edk2.groups.io" , "discuss@edk2.groups.io" Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,aladyshev22@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="kUFF/3kL"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, Chang! Did you have time to test libmctp MCTP KCS binding solution? Here are some updates from my end. As I was saying, I was working on the Linux kernel binding solution. And now I've finished the initial implementation of the Linux kernel binding driver for the MCTP-over-KCS binding and proposed all the patches upstream (https://www.spinics.net/lists/kernel/msg4949173.html). I've also updated instructions in my repo https://github.com/Kostr/PLDM (the guide for the kernel binding solution and all the necessary Linux kernel patches can be found here https://github.com/Kostr/PLDM/tree/master/mctp-kernel). So now you can use Linux driver instead of the libmctp utility on the BMC s= ide. Couple of things that I've noticed in the development process: - `MctpSubmitCommand` receives 'MctpSourceEndpointId'/'MctpDestinationEndpointId' as arguments. But these values aren't actually used. The current code just uses EIDs that were set via PCDs (https://github.com/tianocore/edk2-platforms/blob/d03a60523a6086d200d3eb1e2= f25530bf1cb790e/Features/ManageabilityPkg/Universal/MctpProtocol/Common/Mct= pProtocolCommon.c#L178) - According to the specification DSP0236 (section 8.2) MCTP EID 0 to 7 are reserved. It is critical that we do not use them since MCTP Linux kernel subsystem checks that part. So we probably need to add some check to the `MctpSubmitCommand` that would verify that we don't use reserved EIDs. Best regards, Konstantin Aladyshev On Thu, Sep 21, 2023 at 5:32=E2=80=AFAM Chang, Abner = wrote: > > [AMD Official Use Only - General] > > Hi Aladyshev, > Thanks for providing the details, I will take a look at your code first, = implement it at my end and then response to your question. > > Abner > > > -----Original Message----- > > From: Konstantin Aladyshev > > Sent: Friday, September 8, 2023 8:57 PM > > To: Chang, Abner > > Cc: devel@edk2.groups.io; discuss@edk2.groups.io > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KC= S > > > > Caution: This message originated from an External Source. Use proper ca= ution > > when opening attachments, clicking links, or responding. > > > > > > Hi, Chang! > > > > I've finished my initial implementation of the MCTP over KCS binding. > > You can find 'edk2-platform' patches and 'openbmc' patches along with > > all of the instructions in my repository > > https://github.com/Kostr/PLDM. I hope you'll be able to reproduce > > everything on your hardware configuration. Feel free to ask any > > questions. > > Also I've sent all the openbmc patches upstream, hope they will get > > accepted soon. > > As for the 'edk2-platform' patches, right now I don't fully understand > > how to write them correctly to keep IPMI over KCS stack working. I > > think here I would need your help. Right now I've commited them to my > > `edk2-platforms` fork > > https://github.com/tianocore/edk2- > > platforms/commit/99a6c98a63b37f955c0d0480149b84fcc3a03f74 > > > > Couple of questions/notices: > > 1) You've said that we can differentiate MCTP by the transfer token, > > but it is not passed to the 'KcsTransportSendCommand' function > > https://github.com/tianocore/edk2- > > platforms/blob/bb6841e3fd1c60b3f8510b4fc0a380784e05d326/Features/ > > ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsComm > > on.c#L414 > > > > 2) What function should know about the > > MANAGEABILITY_MCTP_KCS_HEADER? > > Keep in mind that this header includes 'ByteCount' for the incoming > > data size that we need to read. > > - KcsTransportSendCommand or CommonMctpSubmitMessage ? > > (https://github.com/tianocore/edk2- > > platforms/blob/master/Features/ManageabilityPkg/Library/ManageabilityTr= a > > nsportKcsLib/Common/KcsCommon.c) > > (https://github.com/tianocore/edk2- > > platforms/blob/master/Features/ManageabilityPkg/Universal/MctpProtocol/ > > Common/MctpProtocolCommon.c)? > > > > 3) As I've said earlier I think it would be good to add > > MANAGEABILITY_MCTP_KCS_TRAILER to the Mctp.h > > > > 4) Not sure if it is a good idea to pass these parameters to the > > MctpSubmitCommand protocol function: > > ``` > > UINT8 MctpType, > > BOOLEAN RequestDataIntegrityCheck, > > ``` > > (https://github.com/tianocore/edk2- > > platforms/blob/master/Features/ManageabilityPkg/Include/Protocol/MctpPr > > otocol.h) > > Shouldn't it be in the `RequestData` directly since it is more of a > > payload than a header for the MCTP? I don't know the specification > > very well, but what if the RequestDataIntegrityCheck would be set in > > the response? Who would need to check the integrity of the payload > > buffer in that case? MCTP library or the code calling the MCTP > > library? > > > > 5) Haven't tested the PldmProtocol, maybe it also needs some correction= s. > > > > Feel free to ask any questions about my solution. > > > > Right now I'll probably focus on the Linux kernel driver for the MCTP > > over KCS binding. So if you want to finish edk2-platforms code based > > on my patches, feel free to do it. If not, I'll try to get back to it > > after I finish the Linux kernel driver. > > > > Best regards, > > Konstantin Aladyshev > > > > On Fri, Sep 1, 2023 at 8:58=E2=80=AFAM Chang, Abner > > wrote: > > > > > > [AMD Official Use Only - General] > > > > > > See my answer below, > > > > > > > -----Original Message----- > > > > From: devel@edk2.groups.io On Behalf Of > > > > Konstantin Aladyshev via groups.io > > > > Sent: Friday, September 1, 2023 12:02 AM > > > > To: Chang, Abner > > > > Cc: devel@edk2.groups.io; discuss@edk2.groups.io > > > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP ove= r > > KCS > > > > > > > > Caution: This message originated from an External Source. Use prope= r > > caution > > > > when opening attachments, clicking links, or responding. > > > > > > > > > > > > As I've said there is nothing like "KCS completion code" in the MCT= P > > > > over KCS binding specification > > > > > > (https://www.dmtf.org/sites/default/files/standards/documents/DSP0254_1 > > > > .0.0.pdf). > > > > The response packet should have the same structure as a request. I.= e. > > > > a packet with MANAGEABILITY_MCTP_KCS_HEADER and PEC. > > > > > > > > Currently I'm writing "MCTP over KCS" binding for the OpenBMC libmc= tp > > > > project. So I can send whatever I want, I don't think my output wou= ld > > > > be any useful to you. But I've asked this question in the community > > > > and they also confirmed that the response packet has the same > > > > structure. > > > > > > (https://discord.com/channels/775381525260664832/7787906385638850 > > > > 86/1146782595334549554) > > > > > > > > Now I'm a little bit confused about the `KcsTransportSendCommand` > > > > function. It has the following arguments for the function output: > > > > ``` > > > > OUT UINT8 *ResponseData OPTIO= NAL, > > > > IN OUT UINT32 *ResponseDataSize OPTI= ONAL > > > > ``` > > > > Should we include MCTP_TRANSPORT_HEADER/MCTP_MESSAGE_HEADER > > to > > > > this > > > > output or not? > > > If the MCTP KCS packet for host->BMC and BMC->host are in the same > > structure, then yes, the response data from BMC should includes > > MCTP_TRANSPORT_HEADER/MCTP_MESSAGE_HEADER in my opinion, as this > > is defined in MCTP base protocol. > > > > > > So let me explain the implementation for MCTP over KCS and what do we > > miss now. > > > > > > A. MCTP protocol driver linked with KCS Transport interface library > > > - In MCTP protocol driver, if the transport interface is KCS then > > > 1. MCTP protocol driver builds up the MCTP KCS transport heade= r, which > > is DefBody, NetFunc and ByeCount > > > 2. MCTP protocol driver builds up the MCTP payload > > > 3. MCTP protocol driver builds up the MCTP KCS transport trail= er, which > > is PEC. > > > Above three steps are already implemented. > > > PEC is calculated by MCTP protocol driver and should be verifi= ed by KCS > > using the same algorithm in my understanding of spec. > > > > > > B. In KCS Transport interface library > > > 1. KCS Transport interface library sends the transport header g= ot from > > TransportToken. Same behavior for IPMI protocol, but different content.= KCS > > Transport interface library doesn't have to understand this. > > > 2. KCS Transport interface library sends the payload > > > 3. KCS Transport interface library sends the transport trailer = got from > > TransportToken. Same behavior for IPMI protocol, but different content.= KCS > > Transport interface library doesn't have to understand this. > > > Above three steps are already implemented. > > > > > > Then, if Manageability protocol is MCTP, we skip reading respo= nses > > header (Not implemented) > > > For reading response data > > > 1. If the ResponseData and ResponseSize is valid in the give= n > > TransportToken, then we read ResponseSize data from KCS. (Already > > implemented) > > > 2. if Manageability protocol is MCTP, then we skip reading r= esponses > > header again (Not implemented) > > > Now the response is returned to MCTP protocol driver > > > > > > C. In MCTP protocol driver, we expect to get the whole MCTP over KCS > > packet response, that includes DefBody, NetFunc and ByeCount, MCTP > > message and PEC. > > > 1. MCTP protocol driver verifies the returned PEC with the p= ayload. > > > 2. Strip out DefBody, NetFunc, ByeCount and PEC and then ret= urns it to > > upper layer (e.g., MCTP transport interface library). Returns only MCTP > > Transport header and MCTP packet payload as it shows in MCTP base proto= col > > spec. > > > Above is not implemented > > > > > > D. In MCTP transport interface library, we can strip out MCTP transpo= rt > > header and then return it to upper layer (e.g., PLDM protocol driver). > > > Above is not implemented. > > > > > > E. In PLDM protocol driver, > > > 1. we verify the Message Integrity Check if the Message Type = requests it. > > > 2. we can remove MCTP message type then return it to upper la= yer (e.g., > > PLDM SMBIOS transfer) > > > Above is not implemented. > > > > > > We didn=E2=80=99t implement BMC->Host in step C, D and E as our curre= nt demand is > > to send the SMBIOS table to BMC, which doesn't require the response dat= a if I > > am not wrong. > > > Let me know if it is problematic in the above process. > > > > > > Thanks and regards, > > > Abner > > > > > > > > > > > > > > > > > Best regards, > > > > Konstantin Aladyshev > > > > > > > > On Thu, Aug 31, 2023 at 6:52=E2=80=AFPM Chang, Abner > > > > > > wrote: > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > But wait, wee my another comment below, > > > > > > > > > > > -----Original Message----- > > > > > > From: Chang, Abner > > > > > > Sent: Thursday, August 31, 2023 11:42 PM > > > > > > To: devel@edk2.groups.io; aladyshev22@gmail.com > > > > > > Cc: discuss@edk2.groups.io > > > > > > Subject: RE: [edk2-devel] [edk2-discuss] PLDM messages via MCTP > > over > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: devel@edk2.groups.io On Behalf O= f > > > > > > > Konstantin Aladyshev via groups.io > > > > > > > Sent: Thursday, August 31, 2023 10:57 PM > > > > > > > To: Chang, Abner > > > > > > > Cc: discuss@edk2.groups.io; devel@edk2.groups.io > > > > > > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MC= TP > > over > > > > KCS > > > > > > > > > > > > > > Caution: This message originated from an External Source. Use= proper > > > > > > caution > > > > > > > when opening attachments, clicking links, or responding. > > > > > > > > > > > > > > > > > > > > > > (I don see what is the response header for MCTP KCS in spec= though, > > > > does > > > > > > it > > > > > > > mention the KCS response?). > > > > > > > > > > > > > > The spec doesn't explicitly mention that the format of a send= and > > > > > > > response packets differ. So I assume it is the same and it is > > > > > > > described at the "Figure 1 =E2=80=93 MCTP over KCS Packet For= mat" > > > > > > > > > > > > > > > > > > > (https://www.dmtf.org/sites/default/files/standards/documents/DSP0254_1 > > > > > > > .0.0.pdf) > > > > > > > Therefore the format of a response would look like this: > > > > > > > ``` > > > > > > > MANAGEABILITY_MCTP_KCS_HEADER > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Include/Library/Managea > > > > > > > bilityTransportMctpLib.h) > > > > > > > MCTP_TRANSPORT_HEADER > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Industry > > > > > > > Standard/Mctp.h) > > > > > > > MCTP_MESSAGE_HEADER > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Industry > > > > > > > Standard/Mctp.h) > > > > > > > < response data> > > > > > > What do you see the KCS response from BMC? You probably right a= s > > the > > > > > > header and trailer are labeled in different colors =F0=9F=98=8A= . Could you please > > > > enable > > > > > > the debug message to capture it? > > > > > > > > > > > > > PEC > > > > > > > (Probably we need to define > > > > MANAGEABILITY_MCTP_KCS_TRAILER) > > > > > > > ``` > > > > > > We have MANAGEABILITY_MCTP_KCS_HEADER defined but no > > > > > > MANAGEABILITY_MCTP_KCS_TRAILER as it is hardcoded to one byte. > > > > > > If the KCS response is PEC, then yes, we can create > > > > > > MANAGEABILITY_MCTP_KCS_TRAILER for KCS transport interface. > > > > > > > > > > In the implementation, PEC is calculated in MCTP protocol and sen= d > > through > > > > KCS as the KCS packet trailer. So, when we send the MCTP request th= rough > > > > KCS, KCS shouldn't respond the PEC to upper stack, right? I still t= hink the > > > > response should be the KCS completion code. The debug message from > > your > > > > end may help to clarify this as your BMC has the MCTP KCS > > implementation. > > > > > > > > > > Thanks > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > So in the "KcsTransportSendCommand" > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > platforms/blob/14553d31c72afa7289f6a2555b6e91f4f715a05a/Features/ > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsComm > > > > > > > on.c#L414) > > > > > > > we can check if we transfer is MCTP (based on > > > > > > > "TransportToken->ManagebilityProtocolSpecification =3D=3D MCT= P" like > > > > > > > you've suggested) and handle response accordingly. > > > > > > > > > > > > > > But which headers should we check in this function? Only > > > > > > > > > > > > > > > > > > > MANAGEABILITY_MCTP_KCS_HEADER/MANAGEABILITY_MCTP_KCS_TRAILER > > > > > > > ? > > > > > > Yes, only check header and trailer for transport interface. > > > > > > > > > > > > > What about > > MCTP_TRANSPORT_HEADER/MCTP_MESSAGE_HEADER? > > > > Do > > > > > > we > > > > > > > need to > > > > > > > check them here as well? Or do we need to check them somewher= e > > > > upper > > > > > > > the call stack? > > > > > > We should leave this to MCTP protocol driver as this is belong = to > > protocol > > > > > > layer, the upper layer stack. > > > > > > > > > > > > Thanks > > > > > > Abner > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Konstantin Aladyshev > > > > > > > > > > > > > > On Thu, Aug 31, 2023 at 7:59=E2=80=AFAM Chang, Abner > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > > Hi Aladyshev, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Konstantin Aladyshev > > > > > > > > > Sent: Wednesday, August 30, 2023 11:09 PM > > > > > > > > > To: Chang, Abner > > > > > > > > > Cc: discuss@edk2.groups.io; devel@edk2.groups.io > > > > > > > > > Subject: Re: [edk2-discuss] PLDM messages via MCTP over K= CS > > > > > > > > > > > > > > > > > > Caution: This message originated from an External Source.= Use > > proper > > > > > > > caution > > > > > > > > > when opening attachments, clicking links, or responding. > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > I've started to implement MCTP over KCS binding for the l= ibmctp > > > > > > > > > (https://github.com/openbmc/libmctp) and test it with the > > current > > > > code > > > > > > > > > in the ManageabilityPkg. > > > > > > > > > > > > > > > > > > I was able successfully send the MCTP packet to the BMC, = but right > > > > now > > > > > > > > > I'm having some troubles with receiving the answer back. > > > > > > > > > > > > > > > > > > I think I've found some bug in the `KcsTransportSendComma= nd` > > code. > > > > > > > > > > > > > > > > > > After it sends data over KCS in expects a responce starti= ng with a > > > > > > > > > 'IPMI_KCS_RESPONSE_HEADER' > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > platforms/blob/14553d31c72afa7289f6a2555b6e91f4f715a05a/Features/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsComm > > > > > > > > > on.c#L476 > > > > > > > > > > > > > > > > > > Isn't it wrong, assuming that the right header in case of= MCTP > > should > > > > > > > > > be 'MANAGEABILITY_MCTP_KCS_HEADER' ? > > > > > > > > > > > > > > > > > > I guess the 'IpmiHelperCheckCompletionCode' check after t= he data > > > > > > > > > receive is also not relevant for the MCTP. > > > > > > > > > > > > > > > > > > > > > > > > This is something I don=E2=80=99t really sure as I can't ve= rify the response > > > > payload > > > > > > > because our BMC doesn't have the code to handle MCTP over KCS > > > > > > command. > > > > > > > However it is appreciated if community can help to verify thi= s. As I can > > > > > > > remember, I can see the return KCS status is 0xC1, the invali= d > > command. > > > > > > Thus I > > > > > > > think if we do a MCTP over KCS, the first response is still K= CS response > > > > > > header. > > > > > > > > This is not what do you see on the BCM it does support MCTP= over > > > > KCS? If > > > > > > > so, then I would like to have your help to correct this code. > > > > > > > > > > > > > > > > > > > > > > > > > > Since 'ManageabilityTransportKcsLib' can be used both for= IPMI > > and > > > > > > > > > MCTP, how should we deal with this? > > > > > > > > If KcsCommon.c, we can have different code path for the giv= en > > protocol > > > > > > > GUID. e.g., if (TransportToken->ManagebilityProtocolSpecifica= tion =3D=3D > > > > MCTP). > > > > > > > > Then skip reading the KCS_REPOSNSE_HEADER or to read the > > > > > > > MCTP_RESPONSE_HEADER (I don see what is the response header f= or > > > > MCTP > > > > > > > KCS in spec though, does it mention the KCS response?). > > > > > > > > > > > > > > > > Thanks > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Konstantin Aladyshev > > > > > > > > > > > > > > > > > > On Wed, Aug 23, 2023 at 5:18=E2=80=AFAM Chang, Abner > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > > > > > > Please see my answers inline. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: discuss@edk2.groups.io = On > > > > Behalf > > > > > > Of > > > > > > > > > > > Konstantin Aladyshev via groups.io > > > > > > > > > > > Sent: Wednesday, August 23, 2023 1:54 AM > > > > > > > > > > > To: Chang, Abner > > > > > > > > > > > Cc: discuss@edk2.groups.io; devel@edk2.groups.io > > > > > > > > > > > Subject: Re: [edk2-discuss] PLDM messages via MCTP ov= er KCS > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an External Sou= rce. Use > > > > proper > > > > > > > > > caution > > > > > > > > > > > when opening attachments, clicking links, or respondi= ng. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the answer! > > > > > > > > > > > > > > > > > > > > > > I was a little bit confused about the part, that in t= he same > > package > > > > I > > > > > > > > > > > actually need to provide different library implementa= tions for > > the > > > > > > > > > > > same 'ManageabilityTransportLib', thanks for the clar= ification! > > > > > > > > > > > I think your DSC example should go into the package > > > > documentation. > > > > > > > > > > Yes, this is a good idea. I will update it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for me, I'm working with the OpenBMC distribution > > > > > > > > > > > (https://github.com/openbmc/openbmc) and my goal is t= o > > > > transfer > > > > > > > data > > > > > > > > > > > from the BIOS to the BMC via MCTP/PLDM. > > > > > > > > > > > Currently there is no solution for the MCTP over KCS = binding in > > > > Linux, > > > > > > > > > > > so I need to add this support: > > > > > > > > > > > - either to the MCTP userspace library > > > > > > > > > > > (https://github.com/openbmc/libmctp) [old OpenBMC way= , > > but > > > > > > > probably > > > > > > > > > > > easier] > > > > > > > > > > > - or to the MCTP kernel binding > > > > > > > > > > > > > > > (https://github.com/torvalds/linux/tree/master/drivers/net/mctp) > > > > > > > > > > > [modern mctp Linux driver approach] > > > > > > > > > > > > > > > > > > > > > > Both don't sound like an easy task, so can I ask, wha= t MC (i.e. > > > > > > > > > > > management controller) device and firmware do you use= on > > the > > > > other > > > > > > > > > > > side of the MCTP KCS transmissions? > > > > > > > > > > > > > > > > > > > > We use OpenBMC as well, but as you mention there are so= me > > > > missing > > > > > > > pieces > > > > > > > > > to fully support manageability between host and BMC. > > > > > > > > > > We don=E2=80=99t have code to handle MCTP IPMI either, = the edk2 > > > > > > > ManageabilityPkg > > > > > > > > > provides the framework while MCTP/PLDM/KCS implementation > > > > > > provides > > > > > > > a > > > > > > > > > sample other than IPMI/KCS to prove the flexibility of > > > > ManageabilityPkg. > > > > > > > > > > Actually, MCTP over KCS is not supported in our BMC fir= mware > > yet, > > > > > > thus > > > > > > > > > BMC just returns the invalid command. However, the transp= ort > > > > > > framework > > > > > > > > > has been verified to make sure the implementation works f= ine as > > > > expect. > > > > > > > > > > We need help from community to provide more manageabili= ty > > > > > > protocols > > > > > > > and > > > > > > > > > transport interface libraries to this package. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You've also mentioned PLDM SMBIOS, isn't it covered b= y the > > > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Universal/PldmSmbiosTr > > > > > > > > > > > ansferDxe/PldmSmbiosTransferDxe.c > > > > > > > > > > > ? > > > > > > > > > > Ah hah, yes I forget I upstream it. > > > > > > > > > > > > > > > > > > > > Please just feel free to send patch to make more functi= onalities to > > > > this > > > > > > > > > package. > > > > > > > > > > Thanks > > > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > Konstantin Aladyshev > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 22, 2023 at 7:26=E2=80=AFPM Chang, Abner > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > > > > > > > > > > Hi Aladyshev, > > > > > > > > > > > > We use library class to specify the desire transpor= t interface > > for > > > > the > > > > > > > > > > > management protocol, such as MCTP, PLDM and IPMI. Thi= s > > way > > > > we > > > > > > can > > > > > > > > > > > flexibly support any transport interface for the mana= gement > > > > protocol. > > > > > > > > > > > > > > > > > > > > > > > > Here is the example of using ManageabilityPkg, whic= h is > > PLDM > > > > over > > > > > > > MCTP > > > > > > > > > > > over KCS. > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/IpmiProtocol/Dxe/IpmiProtocolDxe.inf > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTranspo= r > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocolDxe.i= nf > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTranspo= r > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/PldmProtocol/Dxe/PldmProtocolDxe.i= nf > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTranspo= r > > > > > > > > > > > tMctpLib/Dxe/DxeManageabilityTransportMctp.inf > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > So you can implement ManageabilityTransport library= for > > either > > > > > > > industry > > > > > > > > > > > standard or proprietary implementation for the specif= ic > > > > management > > > > > > > > > > > protocol. > > > > > > > > > > > > > > > > > > > > > > > > BTW, We do have PLDM SMBIOS over MCTP implementatio= n > > but > > > > > > not > > > > > > > > > > > upstream yet. > > > > > > > > > > > > > > > > > > > > > > > > Hope this information helps. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: discuss@edk2.groups.io > > On > > > > > > > Behalf Of > > > > > > > > > > > > > Konstantin Aladyshev via groups.io > > > > > > > > > > > > > Sent: Tuesday, August 22, 2023 7:00 PM > > > > > > > > > > > > > To: discuss ; > > devel@edk2.groups.io > > > > > > > > > > > > > Subject: [edk2-discuss] PLDM messages via MCTP ov= er KCS > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an External= Source. > > Use > > > > > > > proper > > > > > > > > > > > caution > > > > > > > > > > > > > when opening attachments, clicking links, or resp= onding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to build `ManageabilityPkg` from the e= dk2- > > platforms > > > > > > > > > > > > > repo to issue PLDM messages via MCTP over KCS. I= s it > > possible > > > > > > with > > > > > > > > > > > > > the current code? I see all the building blocks, = but have > > trouble > > > > > > > > > > > > > putting it all together. > > > > > > > > > > > > > > > > > > > > > > > > > > The main question that bothers me is what impleme= ntation > > > > should > > > > > > I > > > > > > > set > > > > > > > > > > > > > for the `ManageabilityTransportLib`? > > > > > > > > > > > > > By default it is set to dummy > > > > `BaseManageabilityTransportNull.inf` > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/ManageabilityPkg.dsc). > > > > > > > > > > > > > > > > > > > > > > > > > > On one case to get PLDM via MCTP it looks that I = need to set > > it > > > > to > > > > > > > > > > > > > `DxeManageabilityTransportMctp.inf` > > > > > > > > > > > > > ManageabilityTransportLib| > > > > > > > <...>/DxeManageabilityTransportMctp.inf > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/ManageabilityTr= a > > > > > > > > > > > > > nsportMctpLib/Dxe/DxeManageabilityTransportMctp.i= nf) > > > > > > > > > > > > > > > > > > > > > > > > > > But on the other case if I want MCTP over KCS I n= eed to set > > it to > > > > > > > > > > > > > `DxeManageabilityTransportKcs.inf` > > > > > > > > > > > > > ManageabilityTransportLib| > > > > > > <...>/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/ManageabilityTr= a > > > > > > > > > > > > > nsportKcsLib/Dxe/DxeManageabilityTransportKcs.inf= ) > > > > > > > > > > > > > > > > > > > > > > > > > > What is the right way to resolve this? > > > > > > > > > > > > > > > > > > > > > > > > > > There are no platforms in the repo that actually = implement > > > > > > > PLDM/MCTP > > > > > > > > > > > > > functionality, so there is no example that I can = use as a > > > > reference. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > Konstantin Aladyshev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#109175): https://edk2.groups.io/g/devel/message/109175 Mute This Topic: https://groups.io/mt/100897530/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-