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 A3663740034 for ; Wed, 4 Oct 2023 17:57:19 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=UQUl2imDLt6Rz4fKij7QpIcctEt5yR1Qo9FMVqV2f+s=; 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=1696442238; v=1; b=Bba3M7inQIuiM+2tkHX7yYHXCwseOMYA4UHy7Dz7l90cKYRfIvoKY3go82NYxZlJKknhsT7F wkww+1EROga8o+62fZ4Fvwtxzabi3lF//8GtWtJ6xgR08oyhZDIfCidLTo0J4GVYGcsPVmn9mN0 pTebSwgZnVqMzT2lmtoG5/Yo= X-Received: by 127.0.0.2 with SMTP id IoHyYY7687511xkVxdLLhsad; Wed, 04 Oct 2023 10:57:18 -0700 X-Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) by mx.groups.io with SMTP id smtpd.web11.439.1696442237448322259 for ; Wed, 04 Oct 2023 10:57:17 -0700 X-Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-79df12ff0f0so32892241.3; Wed, 04 Oct 2023 10:57:17 -0700 (PDT) X-Gm-Message-State: vtHFmKHecflSVZzSxeMdgRSvx7686176AA= X-Google-Smtp-Source: AGHT+IEePbMkk99Q7NzQSpfsL6TDTHgVhh9xOV1HutLB/OOoq1HnRdpJ8Omcyd1qnQzVnIIVhRKBlhj8JDQUzX5KhI0= X-Received: by 2002:a05:6102:508:b0:452:72ec:27ea with SMTP id l8-20020a056102050800b0045272ec27eamr3040396vsa.23.1696442236354; Wed, 04 Oct 2023 10:57:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Konstantin Aladyshev" Date: Wed, 4 Oct 2023 20:57:05 +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=Bba3M7in; 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 > That is great, and I'm surprised there are some build errors at your 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. > How do you think we just send it to the mailing list for review and 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. 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/1c8d0d3fa403b47a34667f7f690a= dd7822163111/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpPr= otocolCommon.c#L178 What can we do about that? > 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/master 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 really 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 tell when they would be merged. For me it looks like they are mostly ready: 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 upstream. Linux kernel development is not what I do every day, so I'm not sure how long it would take. But I'm pretty determined to finish the work and push my driver upstream. Currently there are some questions regarding Linux KCS subsystem, so along with the KCS subsystem creator we have to figure out how to rewrite the subsystem correctly. So this can take some time. After the code is pushed to the torvalds/linux, it would be picked up by the openbmc/linux automatically. Best regards, Konstantin Aladyshev On Wed, Oct 4, 2023 at 7:12=E2=80=AFPM Chang, Abner w= rote: > > [AMD Official Use Only - General] > > > That is great, and I'm surprised there are some build errors at your end. > How do you think we just send it to the mailing list for review and 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 t= ake 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 <= discuss@edk2.groups.io> > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages via MCTP over KCS > > Caution: This message originated from an External Source. Use proper caut= ion 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 kernel > 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/Mctp= ProtocolCommon.c > b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCom= mon.c > index 79501d27aa..345c6da81a 100644 > --- a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtoco= lCommon.c > +++ b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtoco= lCommon.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)MctpKcsTrail= er; > diff --git a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpPro= tocol.c > b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.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/1c8d0d3fa403b47a34667f= 7f690add7822163111 > > > > I combined MCTP over KCS changes and IPMI over KCS functionality in Kcs= CommonLib.c. I also created MANAGEABILITY_MCTP_KCS_TRAILER as you suggested= . The source EID and destination EID are checked in MctpSubmitCommand as we= ll. IPMI/KCS functionality is verified and works fine after this change. > > As I am no able to use the corresponding change you made on OpenBMC sit= e at my end, could you please help to verify my updates on your machine? Le= t's see how it works. > > I also consider to migrate the code that generates MCTP over KCS header= /trailer from MctpProtocolCommon.c to KcsCommonLib.c, maybe after we verify= ing 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 MCTP 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 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 side. > > > > > > 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/d03a60523a6086d200d3eb1e2f25530bf1cb790e/Features/ > > > ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon. > > > 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 f= irst, > > > 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 o= ver > > > KCS > > > > > > > > > > Caution: This message originated from an External Source. Use pro= per > > > caution > > > > > when opening attachments, clicking links, or responding. > > > > > > > > > > > > > > > Hi, Chang! > > > > > > > > > > I've finished my initial implementation of the MCTP over KCS bind= ing. > > > > > 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 g= et > > > > > accepted soon. > > > > > As for the 'edk2-platform' patches, right now I don't fully under= stand > > > > > 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 t= o 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 tok= en, > > > > > 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 incomi= ng > > > > > data size that we need to read. > > > > > - KcsTransportSendCommand or CommonMctpSubmitMessage ? > > > > > (https://github.com/tianocore/edk2- > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/Manageability= Tra > > > > > nsportKcsLib/Common/KcsCommon.c) > > > > > (https://github.com/tianocore/edk2- > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Universal/MctpProtoco= l/ > > > > > 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/Mctp= Pr > > > > > 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 specificatio= n > > > > > very well, but what if the RequestDataIntegrityCheck would be set= in > > > > > the response? Who would need to check the integrity of the payloa= d > > > > > buffer in that case? MCTP library or the code calling the MCTP > > > > > library? > > > > > > > > > > 5) Haven't tested the PldmProtocol, maybe it also needs some corr= ections. > > > > > > > > > > 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 ba= sed > > > > > on my patches, feel free to do it. If not, I'll try to get back t= o 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 O= f > > > > > > > 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 MC= TP > > > over > > > > > KCS > > > > > > > > > > > > > > Caution: This message originated from an External Source. Use= proper > > > > > caution > > > > > > > when opening attachments, clicking links, or responding. > > > > > > > > > > > > > > > > > > > > > As I've said there is nothing like "KCS completion code" in t= he MCTP > > > > > > > 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 reque= st. 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 outp= ut would > > > > > > > be any useful to you. But I've asked this question in the com= munity > > > > > > > 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 `KcsTransportSendComm= and` > > > > > > > function. It has the following arguments for the function out= put: > > > > > > > ``` > > > > > > > OUT UINT8 *ResponseData= OPTIONAL, > > > > > > > IN OUT UINT32 *ResponseDataSiz= e 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 s= ame > > > > > 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 li= brary > > > > > > - In MCTP protocol driver, if the transport interface is KCS= then > > > > > > 1. MCTP protocol driver builds up the MCTP KCS transport= header, > > > 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= trailer, > > > which > > > > > is PEC. > > > > > > Above three steps are already implemented. > > > > > > PEC is calculated by MCTP protocol driver and should 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 transport he= ader got from > > > > > TransportToken. Same behavior for IPMI protocol, but different co= ntent. > > > 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 tr= ailer got from > > > > > TransportToken. Same behavior for IPMI protocol, but different co= ntent. > > > 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= responses > > > > > header (Not implemented) > > > > > > For reading response data > > > > > > 1. If the ResponseData and ResponseSize is valid in th= e given > > > > > TransportToken, then we read ResponseSize data from KCS. (Already > > > > > implemented) > > > > > > 2. if Manageability protocol is MCTP, then we skip rea= ding responses > > > > > 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 ov= er KCS > > > > > packet response, that includes DefBody, NetFunc and ByeCount, MCT= P > > > > > message and PEC. > > > > > > 1. MCTP protocol driver verifies the returned PEC with= the payload. > > > > > > 2. Strip out DefBody, NetFunc, ByeCount and PEC and th= en returns it > > > to > > > > > upper layer (e.g., MCTP transport interface library). Returns onl= y MCTP > > > > > Transport header and MCTP packet payload as it shows in MCTP base > > > protocol > > > > > spec. > > > > > > Above is not implemented > > > > > > > > > > > > D. In MCTP transport interface library, we can strip out MCTP t= ransport > > > > > header and then return it to upper layer (e.g., PLDM protocol dri= ver). > > > > > > 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 up= per 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 the respon= se 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 messages vi= a MCTP > > > > > over > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: devel@edk2.groups.io On Be= half > > > 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.io > > > > > > > > > > Subject: Re: [edk2-devel] [edk2-discuss] PLDM messages = via > > > MCTP > > > > > over > > > > > > > KCS > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an External Sourc= e. Use > > > proper > > > > > > > > > caution > > > > > > > > > > when opening attachments, clicking links, or responding= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (I don see what is the response header for MCTP KCS i= n 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 Pack= et Format" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (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/Manag= ea > > > > > > > > > > bilityTransportMctpLib.h) > > > > > > > > > > MCTP_TRANSPORT_HEADER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Industr= y > > > > > > > > > > Standard/Mctp.h) > > > > > > > > > > MCTP_MESSAGE_HEADER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Industr= y > > > > > > > > > > Standard/Mctp.h) > > > > > > > > > > < response data> > > > > > > > > > What do you see the KCS response from BMC? You probably r= ight as > > > > > 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 interfac= e. > > > > > > > > > > > > > > > > In the implementation, PEC is calculated in MCTP protocol a= nd send > > > > > through > > > > > > > KCS as the KCS packet trailer. So, when we send the MCTP requ= est > > > through > > > > > > > KCS, KCS shouldn't respond the PEC to upper stack, right? I s= till 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/KcsComm > > > > > > > > > > on.c#L414) > > > > > > > > > > we can check if we transfer is MCTP (based on > > > > > > > > > > "TransportToken->ManagebilityProtocolSpecification =3D= =3D MCTP" like > > > > > > > > > > you've suggested) and handle response accordingly. > > > > > > > > > > > > > > > > > > > > But which headers should we check in this function? Onl= y > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > MANAGEABILITY_MCTP_KCS_HEADER/MANAGEABILITY_MCTP_KCS_TRAILER > > > > > > > > > > ? > > > > > > > > > Yes, only check header and trailer for transport interfac= e. > > > > > > > > > > > > > > > > > > > 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 this is b= elong 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 KCS > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an External S= ource. Use > > > > > proper > > > > > > > > > > caution > > > > > > > > > > > > when opening attachments, clicking links, or respon= ding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > I've started to implement MCTP over KCS binding for= the > > > libmctp > > > > > > > > > > > > (https://github.com/openbmc/libmctp) and test it wi= th 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 > > > `KcsTransportSendCommand` > > > > > code. > > > > > > > > > > > > > > > > > > > > > > > > After it sends data over KCS in expects a responce = starting 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 c= ase of MCTP > > > > > should > > > > > > > > > > > > be 'MANAGEABILITY_MCTP_KCS_HEADER' ? > > > > > > > > > > > > > > > > > > > > > > > > I guess the 'IpmiHelperCheckCompletionCode' check a= fter the > > > data > > > > > > > > > > > > receive is also not relevant for the MCTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is something I don=E2=80=99t really sure as I ca= n't verify the response > > > > > > > payload > > > > > > > > > > because our BMC doesn't have the code to handle MCTP ov= er KCS > > > > > > > > > command. > > > > > > > > > > However it is appreciated if community can help to veri= fy this. As I > > > can > > > > > > > > > > remember, I can see the return KCS status is 0xC1, the = invalid > > > > > command. > > > > > > > > > Thus I > > > > > > > > > > think if we do a MCTP over KCS, the first response is s= till KCS > > > response > > > > > > > > > header. > > > > > > > > > > > This is not what do you see on the BCM it does suppor= t MCTP > > > over > > > > > > > KCS? If > > > > > > > > > > so, then I would like to have your help to correct this= code. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Since 'ManageabilityTransportKcsLib' can be used bo= th for IPMI > > > > > and > > > > > > > > > > > > MCTP, how should we deal with this? > > > > > > > > > > > If KcsCommon.c, we can have different code path for t= he given > > > > > protocol > > > > > > > > > > GUID. e.g., if (TransportToken->ManagebilityProtocolSpe= cification > > > =3D=3D > > > > > > > MCTP). > > > > > > > > > > > Then skip reading the KCS_REPOSNSE_HEADER or to read = the > > > > > > > > > > MCTP_RESPONSE_HEADER (I don see what is the response he= ader > > > for > > > > > > > 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, Abne= r > > > > > > > > > > > > > > > > > > > > > > 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.i= o > > > > > > > > > > > > > > Subject: Re: [edk2-discuss] PLDM messages via M= CTP over > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an Extern= al Source. > > > Use > > > > > > > proper > > > > > > > > > > > > caution > > > > > > > > > > > > > > when opening attachments, clicking links, or re= sponding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the answer! > > > > > > > > > > > > > > > > > > > > > > > > > > > > I was a little bit confused about the part, tha= t in the same > > > > > package > > > > > > > I > > > > > > > > > > > > > > actually need to provide different library impl= ementations > > > for > > > > > the > > > > > > > > > > > > > > same 'ManageabilityTransportLib', thanks for th= e > > > clarification! > > > > > > > > > > > > > > I think your DSC example should go into the pac= kage > > > > > > > documentation. > > > > > > > > > > > > > Yes, this is a good idea. I will update it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for me, I'm working with the OpenBMC distrib= ution > > > > > > > > > > > > > > (https://github.com/openbmc/openbmc) and my goa= l is to > > > > > > > transfer > > > > > > > > > > data > > > > > > > > > > > > > > from the BIOS to the BMC via MCTP/PLDM. > > > > > > > > > > > > > > Currently there is no solution for the MCTP ove= r KCS binding > > > in > > > > > > > Linux, > > > > > > > > > > > > > > so I need to add this support: > > > > > > > > > > > > > > - either to the MCTP userspace library > > > > > > > > > > > > > > (https://github.com/openbmc/libmctp) [old OpenB= MC > > > way, > > > > > but > > > > > > > > > > probably > > > > > > > > > > > > > > easier] > > > > > > > > > > > > > > - or to the MCTP kernel binding > > > > > > > > > > > > > > > > > > > > > (https://github.com/torvalds/linux/tree/master/drivers/net/mc= tp) > > > > > > > > > > > > > > [modern mctp Linux driver approach] > > > > > > > > > > > > > > > > > > > > > > > > > > > > Both don't sound like an easy task, so can I as= k, what MC > > > (i.e. > > > > > > > > > > > > > > management controller) device and firmware do y= ou use on > > > > > the > > > > > > > other > > > > > > > > > > > > > > side of the MCTP KCS transmissions? > > > > > > > > > > > > > > > > > > > > > > > > > > We use OpenBMC as well, but as you mention there = are some > > > > > > > missing > > > > > > > > > > pieces > > > > > > > > > > > > to fully support manageability between host and BMC= . > > > > > > > > > > > > > We don=E2=80=99t have code to handle MCTP IPMI ei= ther, 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 B= MC > > > firmware > > > > > yet, > > > > > > > > > thus > > > > > > > > > > > > BMC just returns the invalid command. However, the = transport > > > > > > > > > framework > > > > > > > > > > > > has been verified to make sure the implementation w= orks fine > > > as > > > > > > > expect. > > > > > > > > > > > > > We need help from community to provide more > > > manageability > > > > > > > > > protocols > > > > > > > > > > and > > > > > > > > > > > > transport interface libraries to this package. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You've also mentioned PLDM SMBIOS, isn't it cov= ered by > > > the > > > > > > > > > > > > > > https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Universal/PldmSmbiosT= r > > > > > > > > > > > > > > ansferDxe/PldmSmbiosTransferDxe.c > > > > > > > > > > > > > > ? > > > > > > > > > > > > > Ah hah, yes I forget I upstream it. > > > > > > > > > > > > > > > > > > > > > > > > > > Please just feel free to send patch to make 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 desire tr= ansport > > > interface > > > > > for > > > > > > > the > > > > > > > > > > > > > > management protocol, such as MCTP, PLDM and IPM= I. This > > > > > way > > > > > > > we > > > > > > > > > can > > > > > > > > > > > > > > flexibly support any transport interface for th= e management > > > > > > > protocol. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Here is the example of using ManageabilityPkg= , which is > > > > > PLDM > > > > > > > over > > > > > > > > > > MCTP > > > > > > > > > > > > > > over KCS. > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/IpmiProtocol/Dxe/IpmiProtocolD= xe.inf > > > > > > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTrans= por > > > > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocolDxe.inf > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTrans= por > > > > > > > > > > > > > > tKcsLib/Dxe/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityPkg/Universal/PldmProtocol/Dxe/PldmProtocolDxe.inf > > > > > { > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ManageabilityTransportLib|ManageabilityPkg/Library/ManageabilityTrans= por > > > > > > > > > > > > > > tMctpLib/Dxe/DxeManageabilityTransportMctp.inf > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So you can implement ManageabilityTransport l= ibrary 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 messages via M= CTP over > > > KCS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Caution: This message originated from an Ex= ternal > > > Source. > > > > > Use > > > > > > > > > > proper > > > > > > > > > > > > > > caution > > > > > > > > > > > > > > > > when opening attachments, clicking links, o= r responding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm trying to build `ManageabilityPkg` from= the edk2- > > > > > platforms > > > > > > > > > > > > > > > > repo to issue PLDM messages via MCTP over = KCS. Is it > > > > > possible > > > > > > > > > with > > > > > > > > > > > > > > > > the current code? I see all the building bl= ocks, but have > > > > > trouble > > > > > > > > > > > > > > > > putting it all together. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The main question that bothers me is 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.dsc)= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On one case to get PLDM via MCTP it looks t= hat I need to > > > set > > > > > it > > > > > > > to > > > > > > > > > > > > > > > > `DxeManageabilityTransportMctp.inf` > > > > > > > > > > > > > > > > ManageabilityTransportLib| > > > > > > > > > > <...>/DxeManageabilityTransportMctp.inf > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/Manageability= Tra > > > > > > > > > > > > > > > > > > > nsportMctpLib/Dxe/DxeManageabilityTransportMctp.inf) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But on the other case if I want MCTP over K= CS I need to > > > set > > > > > it to > > > > > > > > > > > > > > > > `DxeManageabilityTransportKcs.inf` > > > > > > > > > > > > > > > > ManageabilityTransportLib| > > > > > > > > > <...>/DxeManageabilityTransportKcs.inf > > > > > > > > > > > > > > > > (https://github.com/tianocore/edk2- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > platforms/blob/master/Features/ManageabilityPkg/Library/Manageability= Tra > > > > > > > > > > > > > > > > nsportKcsLib/Dxe/DxeManageabilityTransportK= cs.inf) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What is the right way to resolve this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are no platforms in the repo that act= ually > > > 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 (#109329): https://edk2.groups.io/g/devel/message/109329 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-