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 326DA7803EC for ; Thu, 5 Oct 2023 12:31:51 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Y3a7yUlfPwY7Re5KWeJBAXIGjaXqaK10WhD5D+F7ePc=; 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=1696509109; v=1; b=q9A+dB5atHWvZWWY+zPdrNIp/u5JRfrOOBegDsp5J8O49TNzLysEJnbw+eLPKSY097gNOr19 3l2Y6jUN81E3ZscACsFW1Nfqs541rSSYxJLIlcPnFnbc1gefwRk2xDChOX7YJDkQhb3VpD6eQBt vubt0OJ/Vi2ENbA9uanbrM8E= X-Received: by 127.0.0.2 with SMTP id KfwrYY7687511x3Z5RJUuNvH; Thu, 05 Oct 2023 05:31:49 -0700 X-Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) by mx.groups.io with SMTP id smtpd.web11.14047.1696509108852818064 for ; Thu, 05 Oct 2023 05:31:49 -0700 X-Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-49d8fbd307fso408467e0c.3; Thu, 05 Oct 2023 05:31:48 -0700 (PDT) X-Gm-Message-State: VgXGuG6tx6gHsBpCyHOp67e6x7686176AA= X-Google-Smtp-Source: AGHT+IGpNpqBLCJg/sAKotee4l02pA2x9fgtfmeDBL94F4GVDqG9F1w0bJGrS++Bu3QN7ttJqWS9eInnZS07Og0PeCg= X-Received: by 2002:a1f:ca83:0:b0:495:c464:a2fe with SMTP id a125-20020a1fca83000000b00495c464a2femr4678758vkg.2.1696509107600; Thu, 05 Oct 2023 05:31:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Konstantin Aladyshev" Date: Thu, 5 Oct 2023 15:31:35 +0300 Message-ID: Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS To: "Chang, Abner" Cc: "discuss@edk2.groups.io" , "devel@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=q9A+dB5a; 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 I was thinking more about it and I think the right solution would be to move these checks to the EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL code (i.e. https://github.com/changab/edk2-platforms/blob/MCTP_OVER_KCS_UPDATE/F= eatures/ManageabilityPkg/Universal/PldmSmbiosTransferDxe/PldmSmbiosTransfer= Dxe.c) Because only the PldmSmbios protocol code should know such information as expected response sizes for its commands. Best regards, Konstantin Aladyshev On Thu, Oct 5, 2023 at 3:19=E2=80=AFPM Konstantin Aladyshev wrote: > > Also I see that the 'PldmProtocolCommon' code contains array of > expected response sizes for every supported PLDM command: > https://github.com/changab/edk2-platforms/blob/5af7ca1555863288bd2887ca46= 5ad07d74b9868e/Features/ManageabilityPkg/Universal/PldmProtocol/Common/Pldm= ProtocolCommon.c#L24 > > I'm not sure that we should have this, since we don't need to know the > MCTP response size apriori. > This only limits allowed PLDM commands to the supported array: > https://github.com/changab/edk2-platforms/blob/5af7ca1555863288bd2887ca46= 5ad07d74b9868e/Features/ManageabilityPkg/Universal/PldmProtocol/Common/Pldm= ProtocolCommon.c#L261 > > This means that right now I can't execute my simple 'GetPLDMTypes' > command through the 'PldmSubmit' protocol function. > > Best regards, > Konstantin Aladyshev > > On Thu, Oct 5, 2023 at 12:55=E2=80=AFPM Konstantin Aladyshev > wrote: > > > > Shouldn't we update the PLDM protocol's 'PldmSubmit' function to > > receive 'MctpSrcEID'/'MctpDestEID' as incoming parameters? Or maybe > > add some 'PldmInit' function to set those parameters for further PLDM > > communication? > > Because right now the MCTP EIDs are fixed to PCDs with no flexibility > > https://github.com/tianocore/edk2-platforms/blob/d6e36a151ff8365cdc55a6= 914cc5e6138d5788dc/Features/ManageabilityPkg/Universal/PldmProtocol/Common/= PldmProtocolCommon.c#L121 > > > > Best regards, > > Konstantin Aladyshev > > > > On Thu, Oct 5, 2023 at 7:03=E2=80=AFAM Chang, Abner wrote: > > > > > > [AMD Official Use Only - General] > > > > > > > -----Original Message----- > > > > From: discuss@edk2.groups.io On Behalf Of > > > > Konstantin Aladyshev via groups.io > > > > Sent: Thursday, October 5, 2023 1:57 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. > > > > > > > > > > > > > That is great, and I'm surprised there are some build errors at y= our end. > > > > > > > > I'm surprised your compiler didn't catch that since it is all basic > > > > syntax errors. > > > > I've used your https://github.com/changab/edk2- > > > > platforms/tree/MCTP_OVER_KCS_UPDATE > > > > directly. > > > > > > Ah I know why, I forget to rebuild the changes of both PEC and MCTP E= ID after I verifying the functionality of IPMI on the new KbcCommonLib.c. Y= es, I do see the build error now and was fixed at my end. My fault. > > > > > > > > > > > > How do you think we just send it to the mailing list for review a= nd keep > > > > working on other problems based on it.? > > > > > Could you please send the patches out, with you as the author and= I'm the > > > > coauthor? I will review it again on dev mailing list. > > > > > > > > No problem, I can send a patch to the 'edk2-devel' mailing list. > > > > But before that I think I'll write a test app to check if PLDM > > > > protocols work correctly. > > > Ok. > > > > > > > > > > > Also earlier I've pointed to a fact that 'MctpSourceEndpointId' and > > > > 'MctpDestinationEndpointId' aren't actually used in the > > > > 'MctpSubmitMessage' function. > > > > EIDs are always taken from the PCDs: > > > > https://github.com/changab/edk2- > > > > platforms/blob/1c8d0d3fa403b47a34667f7f690add7822163111/Features/ > > > > ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon. > > > > c#L178 > > > > What can we do about that? > > > Ah yes, we should update the algorithm, it is done here: https://gith= ub.com/changab/edk2-platforms/tree/MCTP_OVER_KCS_UPDATE. You have to update= your code here: https://github.com/Kostr/PLDM/blob/master/PldmMessage/Pldm= Message.c > > > And we also need the fix the typo on edk2, https://github.com/changab= /edk2/tree/MCTP_OVER_KCS_UPDATE > > > > > > > > > > > > Btw, how long do you think I would take to merge your changes on > > > > openBMC? > > > > > > > > So as I've described in the https://github.com/Kostr/PLDM/tree/mast= er > > > > there are basically 2 approaches for the MCTP stack in OpenBMC: > > > > (1) userspace approach (legacy, shouldn't be really used now) > > > > (2) kernel approach > > > > > > > > It is hard to tell if OpenBMC patches for the (1) approach will be > > > > merged. Since I've developed the Linux kernel driver (2) nobody rea= lly > > > > cares about (1). > > > > > > > > For the (2) there are a couple of OpenBMC patches which I've helped= to > > > > develop, but I'm just a coathor in them. So it is hard for me to te= ll > > > > when they would be merged. For me it looks like they are mostly rea= dy: > > > > 66591: transport: af-mctp: Add pldm_transport_af_mctp_bind() | > > > > https://gerrit.openbmc.org/c/openbmc/libpldm/+/66591 > > > > 63652: pldm: Convert to using libpldm transport APIs | > > > > https://gerrit.openbmc.org/c/openbmc/pldm/+/63652 > > > > > > > > For the (2) I also need to push the mctp Linux kernel driver upstre= am. > > > > Linux kernel development is not what I do every day, so I'm not sur= e > > > > how long it would take. But I'm pretty determined to finish the wor= k > > > > and push my driver upstream. Currently there are some questions > > > > regarding Linux KCS subsystem, so along with the KCS subsystem crea= tor > > > > we have to figure out how to rewrite the subsystem correctly. So th= is > > > > can take some time. > > > > After the code is pushed to the torvalds/linux, it would be picked = up > > > > by the openbmc/linux automatically. > > > Ok, I got it. Thanks for the detailed information. > > > > > > Regards, > > > Abner > > > > > > > > > > > Best regards, > > > > Konstantin Aladyshev > > > > > > > > On Wed, Oct 4, 2023 at 7:12=E2=80=AFPM Chang, Abner > > > > wrote: > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > > > > That is great, and I'm surprised there are some build errors at y= our end. > > > > > How do you think we just send it to the mailing list for review a= nd keep > > > > working on other problems based on it.? > > > > > Could you please send the patches out, with you as the author and= I'm the > > > > coauthor? I will review it again on dev mailing list. > > > > > > > > > > I will take a look on kernal change. Btw, how long do you think I= would take > > > > to merge your changes on openBMC? > > > > > > > > > > Thanks > > > > > Abner > > > > > > > > > > Get Outlook for Android > > > > > > > > > > ________________________________ > > > > > From: Konstantin Aladyshev > > > > > Sent: Wednesday, October 4, 2023 11:59:16 PM > > > > > To: Chang, Abner > > > > > Cc: devel@edk2.groups.io ; > > > > discuss@edk2.groups.io > > > > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP o= ver KCS > > > > > > > > > > Caution: This message originated from an External Source. Use pro= per > > > > caution when opening attachments, clicking links, or responding. > > > > > > > > > > > > > > > Hi Chang! > > > > > > > > > > Thanks! > > > > > There were a couple of trivial compilation errors, but after I've > > > > > fixed them everything seems to work fine! > > > > > Just in case I've tested the OpenBMC side with the mctp Linux ker= nel > > > > > driver approach > > > > > (https://github.com/Kostr/PLDM/tree/master/mctp-kernel) > > > > > The latest kernel patches can be found here: > > > > > https://lore.kernel.org/lkml/20231003131505.337-1- > > > > aladyshev22@gmail.com/ > > > > > > > > > > Here is a fix for the build errors that I've found: > > > > > ``` > > > > > diff --git > > > > a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProto= c > > > > olCommon.c > > > > > > > > > b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProto > > > > colCommon.c > > > > > index 79501d27aa..345c6da81a 100644 > > > > > --- > > > > a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProto= c > > > > olCommon.c > > > > > +++ > > > > b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProto > > > > colCommon.c > > > > > @@ -193,7 +193,7 @@ SetupMctpRequestTransportPacket ( > > > > > > > > > > // > > > > > // Generate PEC follow SMBUS 2.0 specification. > > > > > - *MctpKcsTrailer->Pec =3D HelperManageabilityGenerateCrc8 > > > > > (MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage, > > > > > MctpKcsHeader->ByteCount); > > > > > + MctpKcsTrailer->Pec =3D HelperManageabilityGenerateCrc8 > > > > > (MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage, > > > > > MctpKcsHeader->ByteCount); > > > > > *PacketBody =3D (UINT8 *)ThisPackage; > > > > > *PacketBodySize =3D MctpKcsHeader->ByteCount; > > > > > *PacketTrailer =3D > > > > (MANAGEABILITY_TRANSPORT_TRAILER)MctpKcsTrailer; > > > > > diff --git > > > > a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol= .c > > > > > b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtoc= ol.c > > > > > index 863b8d471c..247d032b9b 100644 > > > > > --- > > > > a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol= .c > > > > > +++ > > > > b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol= .c > > > > > @@ -79,17 +79,17 @@ MctpSubmitMessage ( > > > > > } > > > > > > > > > > // > > > > > - // Chec source EID and destination EDI. > > > > > + // Check source EID and destination EID > > > > > // > > > > > if ((MctpSourceEndpointId >=3D MCTP_RESERVED_ENDPOINT_START_ID= ) && > > > > > - MctpSourceEndpointId <=3D MCTP_RESERVED_ENDPOINT_END_ID) > > > > > + (MctpSourceEndpointId <=3D MCTP_RESERVED_ENDPOINT_END_ID) > > > > > ) { > > > > > DEBUG ((DEBUG_ERROR, "%a: The value of MCTP source EID (%x) = is > > > > > reserved.\n", func, MctpSourceEndpointId)); > > > > > return EFI_INVALID_PARAMETER; > > > > > } > > > > > > > > > > if ((MctpDestinationEndpointId >=3D > > > > MCTP_RESERVED_ENDPOINT_START_ID) && > > > > > - MctpDestinationEndpointId <=3D MCTP_RESERVED_ENDPOINT_END= _ID) > > > > > + (MctpDestinationEndpointId <=3D MCTP_RESERVED_ENDPOINT_END= _ID) > > > > > ) { > > > > > DEBUG ((DEBUG_ERROR, "%a: The value of MCTP destination EID = (%x) > > > > > is reserved.\n", func, MctpDestinationEndpointId)); > > > > > return EFI_INVALID_PARAMETER; > > > > > ``` > > > > > > > > > > Best regards, > > > > > Konstantin Aladyshev > > > > > > > > > > On Wed, Oct 4, 2023 at 2:52=E2=80=AFPM Chang, Abner > > > > wrote: > > > > > > > > > > > > [AMD Official Use Only - General] > > > > > > > > > > > > Hi Aladyshev, > > > > > > I have updated the change you made and put those code on below = link, > > > > > > https://github.com/changab/edk2- > > > > platforms/commit/1c8d0d3fa403b47a34667f7f690add7822163111 > > > > > > > > > > > > I combined MCTP over KCS changes and IPMI over KCS functionalit= y in > > > > KcsCommonLib.c. I also created MANAGEABILITY_MCTP_KCS_TRAILER as yo= u > > > > suggested. The source EID and destination EID are checked in > > > > MctpSubmitCommand as well. IPMI/KCS functionality is verified and w= orks > > > > fine after this change. > > > > > > As I am no able to use the corresponding change you made on Ope= nBMC > > > > site at my end, could you please help to verify my updates on your = machine? > > > > Let's see how it works. > > > > > > I also consider to migrate the code that generates MCTP over KC= S > > > > header/trailer from MctpProtocolCommon.c to KcsCommonLib.c, maybe a= fter > > > > we verifying PLDM->MCTP->KCS route works well on ManageabilityPkg. > > > > > > > > > > > > Thank you > > > > > > Abner > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Konstantin Aladyshev > > > > > > > Sent: Friday, September 29, 2023 2:18 AM > > > > > > > To: Chang, Abner > > > > > > > Cc: devel@edk2.groups.io; discuss@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. > > > > > > > > > > > > > > > > > > > > > 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 wor= king 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 bindi= ng > > > > > > > solution and all the necessary Linux kernel patches can be fo= und here > > > > > > > https://github.com/Kostr/PLDM/tree/master/mctp-kernel). > > > > > > > So now you can use Linux driver instead of the libmctp utilit= y on the BMC > > > > side. > > > > > > > > > > > > > > Couple of things that I've noticed in the development process= : > > > > > > > - `MctpSubmitCommand` receives > > > > > > > 'MctpSourceEndpointId'/'MctpDestinationEndpointId' as argumen= ts. 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/d03a60523a6086d200d3eb1e2f25530bf1cb790e/Features/ > > > > > > > > > > > ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon. > > > > > > > c#L178) > > > > > > > - According to the specification DSP0236 (section 8.2) MCTP E= ID 0 to 7 > > > > > > > are reserved. It is critical that we do not use them since MC= TP Linux > > > > > > > kernel subsystem checks that part. So we probably need to add= some > > > > > > > check to the `MctpSubmitCommand` that would verify that we do= n'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 you= r 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 vi= a MCTP > > > > over > > > > > > > KCS > > > > > > > > > > > > > > > > > > Caution: This message originated from an External Source.= Use proper > > > > > > > caution > > > > > > > > > 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' patche= s along > > > > with > > > > > > > > > all of the instructions in my repository > > > > > > > > > https://github.com/Kostr/PLDM. I hope you'll be able to r= eproduce > > > > > > > > > everything on your hardware configuration. Feel free to a= sk any > > > > > > > > > questions. > > > > > > > > > Also I've sent all the openbmc patches upstream, hope the= y will get > > > > > > > > > accepted soon. > > > > > > > > > As for the 'edk2-platform' patches, right now I don't ful= ly understand > > > > > > > > > how to write them correctly to keep IPMI over KCS stack w= orking. I > > > > > > > > > think here I would need your help. Right now I've commite= d 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 tran= sfer token, > > > > > > > > > but it is not passed to the 'KcsTransportSendCommand' fun= ction > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > platforms/blob/bb6841e3fd1c60b3f8510b4fc0a380784e05d326/Features/ > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCom= m > > > > > > > > > on.c#L414 > > > > > > > > > > > > > > > > > > 2) What function should know about the > > > > > > > > > MANAGEABILITY_MCTP_KCS_HEADER? > > > > > > > > > Keep in mind that this header includes 'ByteCount' for th= e incoming > > > > > > > > > data size that we need to read. > > > > > > > > > - KcsTransportSendCommand or CommonMctpSubmitMessage ? > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/Manageabili= tyTra > > > > > > > > > nsportKcsLib/Common/KcsCommon.c) > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Universal/MctpProto= col/ > > > > > > > > > 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/Mc= tpPr > > > > > > > > > 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 spec= ification > > > > > > > > > very well, but what if the RequestDataIntegrityCheck woul= d be set in > > > > > > > > > the response? Who would need to check the integrity of th= e payload > > > > > > > > > buffer in that case? MCTP library or the code calling the= MCTP > > > > > > > > > library? > > > > > > > > > > > > > > > > > > 5) Haven't tested the PldmProtocol, maybe it also needs s= ome > > > > corrections. > > > > > > > > > > > > > > > > > > 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 ge= t 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 message= s via > > > > MCTP > > > > > > > over > > > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an External Sou= rce. Use > > > > proper > > > > > > > > > caution > > > > > > > > > > > when opening attachments, clicking links, or respondi= ng. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As I've said there is nothing like "KCS completion co= de" in the > > > > MCTP > > > > > > > > > > > over KCS binding specification > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://www.dmtf.org/sites/default/files/standards/documents/DSP02= 54_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 > > > > > > > libmctp > > > > > > > > > > > project. So I can send whatever I want, I don't think= my output > > > > would > > > > > > > > > > > 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 func= tion output: > > > > > > > > > > > ``` > > > > > > > > > > > OUT UINT8 *Resp= onseData OPTIONAL, > > > > > > > > > > > IN OUT UINT32 *Respons= eDataSize OPTIONAL > > > > > > > > > > > ``` > > > > > > > > > > > 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 in= cludes > > > > > > > > > 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 inte= rface library > > > > > > > > > > - In MCTP protocol driver, if the transport interfac= e is KCS then > > > > > > > > > > 1. MCTP protocol driver builds up the MCTP KCS t= ransport > > > > header, > > > > > > > which > > > > > > > > > is DefBody, NetFunc and ByeCount > > > > > > > > > > 2. MCTP protocol driver builds up the MCTP paylo= ad > > > > > > > > > > 3. MCTP protocol driver builds up the MCTP KCS t= ransport trailer, > > > > > > > which > > > > > > > > > is PEC. > > > > > > > > > > Above three steps are already implemented. > > > > > > > > > > PEC is calculated by MCTP protocol driver and sh= ould be verified > > > > by > > > > > > > KCS > > > > > > > > > using the same algorithm in my understanding of spec. > > > > > > > > > > > > > > > > > > > > B. In KCS Transport interface library > > > > > > > > > > 1. KCS Transport interface library sends the tran= sport header got > > > > from > > > > > > > > > TransportToken. Same behavior for IPMI protocol, but diff= erent > > > > content. > > > > > > > KCS > > > > > > > > > Transport interface library doesn't have to understand th= is. > > > > > > > > > > 2. KCS Transport interface library sends the payl= oad > > > > > > > > > > 3. KCS Transport interface library sends the tran= sport trailer got > > > > from > > > > > > > > > TransportToken. Same behavior for IPMI protocol, but diff= erent > > > > content. > > > > > > > KCS > > > > > > > > > Transport interface library doesn't have to understand th= is. > > > > > > > > > > Above three steps are already implemented. > > > > > > > > > > > > > > > > > > > > Then, if Manageability protocol is MCTP, we skip= reading > > > > responses > > > > > > > > > header (Not implemented) > > > > > > > > > > For reading response data > > > > > > > > > > 1. If the ResponseData and ResponseSize is val= id in the given > > > > > > > > > TransportToken, then we read ResponseSize data from KCS. = (Already > > > > > > > > > implemented) > > > > > > > > > > 2. if Manageability protocol is MCTP, then we = skip reading > > > > responses > > > > > > > > > header again (Not implemented) > > > > > > > > > > Now the response is returned to MCTP protocol driv= er > > > > > > > > > > > > > > > > > > > > C. In MCTP protocol driver, we expect to get the whole= MCTP over > > > > KCS > > > > > > > > > packet response, that includes DefBody, NetFunc and ByeCo= unt, > > > > MCTP > > > > > > > > > message and PEC. > > > > > > > > > > 1. MCTP protocol driver verifies the returned = PEC with the > > > > payload. > > > > > > > > > > 2. Strip out DefBody, NetFunc, ByeCount and PE= C and then > > > > returns it > > > > > > > to > > > > > > > > > upper layer (e.g., MCTP transport interface library). Ret= urns only > > > > MCTP > > > > > > > > > Transport header and MCTP packet payload as it shows in M= CTP base > > > > > > > protocol > > > > > > > > > spec. > > > > > > > > > > Above is not implemented > > > > > > > > > > > > > > > > > > > > D. In MCTP transport interface library, we can strip ou= t MCTP > > > > transport > > > > > > > > > header and then return it to upper layer (e.g., PLDM prot= ocol 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 > > > > layer > > > > > > > (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 current > > > > > > > demand is > > > > > > > > > to send the SMBIOS table to BMC, which doesn't require th= e response > > > > data > > > > > > > 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 mes= sages via > > > > MCTP > > > > > > > > > over > > > > > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: devel@edk2.groups.io On > > > > Behalf > > > > > > > Of > > > > > > > > > > > > > > Konstantin Aladyshev via groups.io > > > > > > > > > > > > > > Sent: Thursday, August 31, 2023 10:57 PM > > > > > > > > > > > > > > To: Chang, Abner > > > > > > > > > > > > > > Cc: discuss@edk2.groups.io; devel@edk2.groups.i= o > > > > > > > > > > > > > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM m= essages via > > > > > > > MCTP > > > > > > > > > over > > > > > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an Extern= al Source. > > > > Use > > > > > > > proper > > > > > > > > > > > > > caution > > > > > > > > > > > > > > when opening attachments, clicking links, or re= sponding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (I don see what is the response header for MC= TP KCS in spec > > > > > > > though, > > > > > > > > > > > does > > > > > > > > > > > > > it > > > > > > > > > > > > > > mention the KCS response?). > > > > > > > > > > > > > > > > > > > > > > > > > > > > The spec doesn't explicitly mention that the fo= rmat 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 Format" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://www.dmtf.org/sites/default/files/standards/documents/DSP02= 54_1 > > > > > > > > > > > > > > .0.0.pdf) > > > > > > > > > > > > > > Therefore the format of a response would look l= ike this: > > > > > > > > > > > > > > ``` > > > > > > > > > > > > > > MANAGEABILITY_MCTP_KCS_HEADER > > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Include/Library/Man= agea > > > > > > > > > > > > > > bilityTransportMctpLib.h) > > > > > > > > > > > > > > MCTP_TRANSPORT_HEADER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Indus= try > > > > > > > > > > > > > > Standard/Mctp.h) > > > > > > > > > > > > > > MCTP_MESSAGE_HEADER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Indus= try > > > > > > > > > > > > > > Standard/Mctp.h) > > > > > > > > > > > > > > < response data> > > > > > > > > > > > > > What do you see the KCS response from BMC? You pr= obably > > > > right as > > > > > > > > > the > > > > > > > > > > > > > header and trailer are labeled in different color= s =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 crea= te > > > > > > > > > > > > > MANAGEABILITY_MCTP_KCS_TRAILER for KCS transport > > > > interface. > > > > > > > > > > > > > > > > > > > > > > > > In the implementation, PEC is calculated in MCTP pr= otocol and > > > > send > > > > > > > > > through > > > > > > > > > > > KCS as the KCS packet trailer. So, when we send the M= CTP request > > > > > > > through > > > > > > > > > > > KCS, KCS shouldn't respond the PEC to upper stack, ri= ght? I still > > > > think > > > > > > > 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/KcsCom= m > > > > > > > > > > > > > > on.c#L414) > > > > > > > > > > > > > > we can check if we transfer is MCTP (based on > > > > > > > > > > > > > > "TransportToken->ManagebilityProtocolSpecificat= ion =3D=3D > > > > MCTP" like > > > > > > > > > > > > > > you've suggested) and handle response according= ly. > > > > > > > > > > > > > > > > > > > > > > > > > > > > But which headers should we check in this funct= ion? 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 > > > > > > > somewhere > > > > > > > > > > > upper > > > > > > > > > > > > > > the call stack? > > > > > > > > > > > > > We should leave this to MCTP protocol driver as t= his 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.grou= ps.io > > > > > > > > > > > > > > > > Subject: Re: [edk2-discuss] PLDM messages v= ia MCTP > > > > over KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an Ex= ternal Source. > > > > Use > > > > > > > > > proper > > > > > > > > > > > > > > caution > > > > > > > > > > > > > > > > when opening attachments, clicking links, o= r responding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've started to implement MCTP over KCS bin= ding for the > > > > > > > libmctp > > > > > > > > > > > > > > > > (https://github.com/openbmc/libmctp) and te= st it with > > > > the > > > > > > > > > current > > > > > > > > > > > code > > > > > > > > > > > > > > > > in the ManageabilityPkg. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was able successfully send the MCTP packe= t 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 > > > > > > > `KcsTransportSendCommand` > > > > > > > > > code. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > After it sends data over KCS in expects a r= esponce starting > > > > with > > > > > > > a > > > > > > > > > > > > > > > > 'IPMI_KCS_RESPONSE_HEADER' > > > > > > > > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/14553d31c72afa7289f6a2555b6e91f4f715a05a/Features/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCom= m > > > > > > > > > > > > > > > > on.c#L476 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Isn't it wrong, assuming that the right hea= der in case of > > > > MCTP > > > > > > > > > should > > > > > > > > > > > > > > > > be 'MANAGEABILITY_MCTP_KCS_HEADER' ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess the 'IpmiHelperCheckCompletionCode'= check after > > > > the > > > > > > > data > > > > > > > > > > > > > > > > receive is also not relevant for the MCTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is something I don=E2=80=99t really sure= as I can't verify 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 this. > > > > As I > > > > > > > can > > > > > > > > > > > > > > remember, I can see the return KCS status is 0x= C1, the invalid > > > > > > > > > command. > > > > > > > > > > > > > Thus I > > > > > > > > > > > > > > think if we do a MCTP over KCS, the first respo= nse is still KCS > > > > > > > response > > > > > > > > > > > > > header. > > > > > > > > > > > > > > > This is not what do you see on the BCM it doe= s support > > > > MCTP > > > > > > > over > > > > > > > > > > > KCS? If > > > > > > > > > > > > > > so, then I would like to have your help to corr= ect 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 pa= th for the > > > > given > > > > > > > > > protocol > > > > > > > > > > > > > > GUID. e.g., if (TransportToken- > > > > >ManagebilityProtocolSpecification > > > > > > > =3D=3D > > > > > > > > > > > MCTP). > > > > > > > > > > > > > > > Then skip reading the KCS_REPOSNSE_HEADER or = to read > > > > the > > > > > > > > > > > > > > MCTP_RESPONSE_HEADER (I don see what is the res= ponse > > > > header > > > > > > > for > > > > > > > > > > > MCTP > > > > > > > > > > > > > > KCS in spec though, does it mention the KCS res= ponse?). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > Abner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Konstantin Aladyshev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 23, 2023 at 5:18=E2=80=AFAM Cha= ng, 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 A= M > > > > > > > > > > > > > > > > > > To: Chang, Abner > > > > > > > > > > > > > > > > > > Cc: discuss@edk2.groups.io; devel@edk2.= groups.io > > > > > > > > > > > > > > > > > > Subject: Re: [edk2-discuss] PLDM messag= es via MCTP > > > > over > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from a= n External > > > > Source. > > > > > > > Use > > > > > > > > > > > proper > > > > > > > > > > > > > > > > caution > > > > > > > > > > > > > > > > > > when opening attachments, clicking link= s, or > > > > responding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the answer! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was a little bit confused about the p= art, that in the > > > > same > > > > > > > > > package > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > actually need to provide different libr= ary > > > > implementations > > > > > > > for > > > > > > > > > the > > > > > > > > > > > > > > > > > > same 'ManageabilityTransportLib', thank= s for the > > > > > > > clarification! > > > > > > > > > > > > > > > > > > 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) an= d my goal > > > > is to > > > > > > > > > > > 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) [o= ld > > > > 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, what > > > > MC > > > > > > > (i.e. > > > > > > > > > > > > > > > > > > management controller) device and firmw= are do you > > > > use on > > > > > > > > > the > > > > > > > > > > > other > > > > > > > > > > > > > > > > > > side of the MCTP KCS transmissions? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We use OpenBMC as well, but as you mentio= n there are > > > > some > > > > > > > > > > > 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 fle= xibility of > > > > > > > > > > > ManageabilityPkg. > > > > > > > > > > > > > > > > > Actually, MCTP over KCS is not supported = in our BMC > > > > > > > firmware > > > > > > > > > yet, > > > > > > > > > > > > > thus > > > > > > > > > > > > > > > > BMC just returns the invalid command. Howev= er, the > > > > transport > > > > > > > > > > > > > framework > > > > > > > > > > > > > > > > has been verified to make sure the implemen= tation works > > > > fine > > > > > > > as > > > > > > > > > > > expect. > > > > > > > > > > > > > > > > > We need help from community to provide mo= re > > > > > > > manageability > > > > > > > > > > > > > protocols > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > transport interface libraries to this packa= ge. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You've also mentioned PLDM SMBIOS, isn'= t it covered > > > > by > > > > > > > the > > > > > > > > > > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Universal/PldmSmbio= sTr > > > > > > > > > > > > > > > > > > ansferDxe/PldmSmbiosTransferDxe.c > > > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > Ah hah, yes I forget I upstream it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please just feel free to send patch to ma= ke more > > > > > > > functionalities 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 d= esire transport > > > > > > > interface > > > > > > > > > for > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > management protocol, such as MCTP, PLDM= and IPMI. > > > > This > > > > > > > > > way > > > > > > > > > > > we > > > > > > > > > > > > > can > > > > > > > > > > > > > > > > > > flexibly support any transport interfac= e for the > > > > management > > > > > > > > > > > protocol. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Here is the example of using Manageab= ilityPkg, which > > > > is > > > > > > > > > PLDM > > > > > > > > > > > over > > > > > > > > > > > > > > MCTP > > > > > > > > > > > > > > > > > > over KCS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/IpmiProtocol/Dxe/IpmiProtocolDxe.inf > > > > > > > > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTra= nspor > > > > > > > > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKc= s.inf > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocolDxe.i= nf > > > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTra= nspor > > > > > > > > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKc= s.inf > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/PldmProtocol/Dxe/PldmProtocolDxe.i= nf > > > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTra= nspor > > > > > > > > > > > > > > > > > > tMctpLib/Dxe/DxeManageabilityTransportM= ctp.inf > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So you can implement ManageabilityTra= nsport library > > > > for > > > > > > > > > either > > > > > > > > > > > > > > industry > > > > > > > > > > > > > > > > > > standard or proprietary implementation = for the specific > > > > > > > > > > > management > > > > > > > > > > > > > > > > > > protocol. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > BTW, We do have PLDM SMBIOS over MCTP > > > > > > > implementation > > > > > > > > > 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 messag= es via MCTP > > > > over > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated fr= om an External > > > > > > > Source. > > > > > > > > > Use > > > > > > > > > > > > > > proper > > > > > > > > > > > > > > > > > > caution > > > > > > > > > > > > > > > > > > > > when opening attachments, clicking = links, or > > > > responding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to build `ManageabilityP= kg` from the > > > > edk2- > > > > > > > > > platforms > > > > > > > > > > > > > > > > > > > > repo to issue PLDM messages via MC= TP over KCS. > > > > Is it > > > > > > > > > possible > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > > > > the current code? I see all the bui= lding blocks, but > > > > have > > > > > > > > > trouble > > > > > > > > > > > > > > > > > > > > putting it all together. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The main question that bothers me i= s what > > > > > > > implementation > > > > > > > > > > > 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.ds= c). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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/Manageabili= tyTra > > > > > > > > > > > > > > > > > > > > > > > > > > > nsportMctpLib/Dxe/DxeManageabilityTransportMctp.inf) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But on the other case if I want MCT= P over KCS I > > > > need to > > > > > > > set > > > > > > > > > it to > > > > > > > > > > > > > > > > > > > > `DxeManageabilityTransportKcs.inf` > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib| > > > > > > > > > > > > > <...>/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/Manageabili= tyTra > > > > > > > > > > > > > > > > > > > > > > > > nsportKcsLib/Dxe/DxeManageabilityTransportKcs.inf) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What is the right way to resolve th= is? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are no platforms in the repo = that actually > > > > > > > implement > > > > > > > > > > > > > > PLDM/MCTP > > > > > > > > > > > > > > > > > > > > functionality, so there is no examp= le 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 (#109353): https://edk2.groups.io/g/devel/message/109353 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-