Skip to content
Arun P. Mohanan edited this page Jun 21, 2023 · 240 revisions

OpenBMC - PMCI - workgroup - To collaborate & implement the PMCI specifications in OpenBMC

Meeting Information:

Please connect to Discord(https://discord.gg/TMNFSSpE84) Voice channel - PMCI (Note: Manually join to PMCI Voice channel).

How to request for a meeting?

Meeting will be scheduled based on need. If you are interested to discuss about a topic, feel free to request via Discord(https://discord.com/channels/775381525260664832/778790638563885086) channel 'mctp-and-pldm'.

Next Meeting

Notes from Discord discussion (4th April 2023)

Cancelling recurring bi-weekly meetings due to less topics and reduced attendance. Special sessions will be scheduled based on need.

Reference: https://discord.com/channels/775381525260664832/778790638563885086/1092663913084092496

Minutes 3rd April 2023 - Cancelled due to low attendance

Minutes 20th March 2023 - Cancelled

Minutes 6th March 2023 - Cancelled

Minutes 20th February 2023 - Cancelled

Minutes 6th February 2023 - Cancelled

Minutes 23rd January 2023

Attendees:

  • Jeremy (Code Construct)
  • Arun, Prithvi (Intel)
  • Tom (NVDIA)
  • Andrew, Rashmica (IBM)
Agenda: AF_MCTP support in libpldm - https://gerrit.openbmc.org/c/openbmc/libpldm/+/59576
Rashmica: Did a walk through of the APIs introduced.

Queries:
Arun: Are the APIs implemented under the assumptions that EIDs & TIDs(Static EID and TID) are known? Or does it support PLDM discovery phase where TID is not known?
Rashmica: At preset the APIs needs preconfigured EID - TID map to work.
Andrew: Current plan is to add minimal support to use AF_MCTP. Existing PLDM implementation expects TIDs to be known. PLDM discovery supports needs to be added separately.
Tom: How does this work if we need to listern for incoming events?
Andrew & Rashmica: There is an implementation of polling on fd, using which the listener can listern to incoming events.
Arun: I see in current implementation, MCTP messages of non PLDM types are discarded. Is it possible to add another daemon which can listen to non PLDM messages(say NVMe-MI) from the same device(same EID)? For a device with multiple MCTP message type supports, would we need more than one socket ? 
Andrew & Jeremy: yes it is possible. Each daemon registers a socket and can get the messages as per registration.

Minutes 9th January 2023

Attendees:

  • Jeremy (Code Construct)
  • Arun, Prithvi, Vikash (Intel)

Closed quickly due to low attendance. No major topics discussed.

Minutes 12th December 2022 - Rescheduled to 19th December

Minutes 28th November 2022 - Cancelled

Minutes 14th November 2022

Attendees:

  • NVIDIA: Tom
  • HCL: Naveen
  • Intel: Sumanth, Krzysztof, Nidhin, Vikash, Prithvi, Anjali, Daiyaan
  • IBM: Andrew, Manoj, Archana
  • Other: Kamal, Karthikeyan, Lola Johnson, Jayashankar, Archana, Pavitra, Kumar, Sagar, Fengling, Troy Lee
Agenda 1 - A tour of libpldm codebase - Manoj

Arun: Are we planning to add other pldm transport support like NCSI over RBT to libpldm?
Andrew: At present we dont have such use case. But we can use libpldm to add the same.
Arun: And BIOS related files(bios.c and bios_table.c) in libpldm are they specific to IBM?
Manoj: No, it's a DMTF standard.
Arun: Is the PDR related implementation concentrating on PLDM responder?
Manoj: Not really, Can you please give some examples?
Arun: When a device acts as endpoint/terminus it will build PDR from scratch. However, for the busowner it is just collecting the PDR and storing it.
Manoj: Currently the implementation has the capability to build PDR and store it in form tree data structure. Even though we have the capability to both generate and store. I believe we have scope to enhance.
Arun: The reason for asking is that we have some patches in review which is NOT using libpldm provided PDR storage mechanism. So in my opinion if we have the support, we can leverage it. 
Arun: Also, can we have PDR parsing APIs in libpldm or is it only for pldm encode/decode APIs?
Tom: Yes. We can add PDR parsing APIs also to libpldm.
Sumanth: What is the migration plan to move towards MCTP Kernel implementation for pldm, Do we have a plan to support both kernel based implementation and existing socket based implementation at the time of migration?
Andrew: Yes, that is how we are planning
Sumanth: So if tomorrow we get to implement to other transport. Hope that can be incorporated with ease
Andrew: Yes that is possible
Naveen: Can we have multiple sockets for each transport?
Manoj: Currently we have a function pldm_open which created the sockets and does the transaction
Naveen: But for other transport like NCSI over RBT how is the plan?
Andrew: today we dont have a common structure to do it. But by using the context it must be possible to solve this issue
Naveen: what is the need to pass socket information. Can we have tid passed to the API and have socket to transport decoding done in libpldm?
Andrew: Yes, we need to pass the context and get rid of backend specific information. then it can map the context to the EID or NCSI.
Arun: Something like, TID is mapped to MctpInfo. In similar way TID can be mapped to NCSI specific info

Agenda 2 - Abstraction layer to support NCSI over RBT - Neveen
Naveen - Discussed about existing pldm_send() APIs, which is using eid as an input param. It should get changed to support multiple transport.
Will be pushing a new set of APIs which will be able to send pldm messages over NCSI over RBT. Also, this should handle the usecase of having identical TID across multiple transport medium.

Minutes 31st October 2022 - Cancelled

Minutes 17th October 2022

Attendees:

  • Intel - Arun, krzysztof
  • ARM - Gilbert
  • IBM - Manoj, Archana
1. Issue with assert in libpldm (fru.c , pdr.c)
Arun: Asserts in the library is causing PLDM demon to exit due to incorrect data from the terminus(eg: incorrect PDR). Can we define return codes to report error back to daemon instead of using asserts?
Manoj: In IBM usecase also we hit similar issue once. In agreement with Arun but need to explore if there is any industry wide standard present to handle this kind of errors other than defining new return codes.
Arun: Agree. Will check for other options and propose the change.

2. PLDM inventory creation and sensor association - https://gerrit.openbmc.org/c/openbmc/pldm/+/51489/1..35/platform-mc/numeric_sensor.cpp#b61
Gilbert: Plan is to use entity-manager for inventory creation. Will be pushing another set of patch set for the same.
Arun: How the sensors will be represented in redfish?
Gilbert: Sensors will be represented under the baseboard URI itself
Arun: Will wait for the review and discuss further.

3. Opinion about having PDR parsing APIs in libpldm - https://gerrit.openbmc.org/c/openbmc/pldm/+/53961/28/platform-mc/terminus.cpp#95
Arun, Gilbert and Manoj in agreement to having PDR parsing APIs in libpldm. Will wait for Tom to confirm.

Opens:
Manoj: FYI: libpldm is moved to new repo. The pending reviews needs to be moved to new repo.
Manoj: IBM is having usecase for PLDMStateSensor and PLDMNumericEffecter. What about others, any plans to add support for the same?
Gilbert: Yes, ARM is also having the usecase.
Arun: Intel also has the usecase and have an OEM implementation in downstream Intel-BMC.

Minutes 3rd October 2022 - Canceled as people are out on Dasara vacation

Minutes 19th September 2022

Attendees:

  • Intel - Arun, krzysztof, Nidhin, Prithvi
  • Nvidia - Toms
Opens:
Arun: I see in this patch(https://gerrit.openbmc.org/c/openbmc/pldm/+/51489) the association dbus path related to sensors is hardcoded. It is not clear how the inventory is created and association is done with PLDM sensor. Can you share your thoughts ?
Tom:  Inventory is NOT coming from FRU I believe. There must be a look up table
Arun: PLDM sensors are associated with all_sensors. The inventory might be created based on PLDM FRU or IPMI FRU.
Tom:  In this patch the association is done with chassis and the same is passed as object path to D-bus. Hope this is a first patch and there will be subsequent patches describing the association. It would be good to comment observations and ask for clarification with Gilbert.
Arun: Agree, will update the comments and we will have another discussion on this on next meet.

Minutes 5 September 2022 - Canceled due to other conflicts and local festival

Minutes 22 August 2022

Attendees:

  • Intel - Arun, Sumanth, Ananth, Anjali, Nidhin, Prithvi
  • NVIDIA - Tom
  • HCL - Naveen Mosesss
  • IBM - ManojKiran
  • Code construct -Jermy
  • Jayashankar, Kumar, Pavithra, Sagar.Srinivas
Agenda:
1. libpldm refactoring
Manoj: Currently libpldm is tightly coupled with pldmd. Hence creating a shared lib would be difficult. Applications cannot use libpldm directly and would need pldmd also to be complied in order to use libpldm. Hence we are splitting libpldm into new repo. We will have its own recipe which makes it easy for lib consumption. Our final goal is to push it to DMTF.
Sumanth: Do you plans to add additional features or only encode/decode APIs?
Manoj: Currently the plan is to separate out existing code so that it is modular.
Tom: Eventually the plan would be shape libpldm as libspdm. With generic implementation so that any platforms can make use of. Add tests/ version support. So we will have quite big scope.
Arun: Will the new repo be under OpenBMC or DMTF ?
Manoj: Currently it will be under OpenBMC. However, discussion with DMTF will continue on making this go in DMTF repos.
Tom: Any PLDM commits pending on this topic?
Manoj: We have 4-5 commits which are in review. Some have dependencies on meson 0.63 due to which CI builds are failing. We can push other patches which dont have dependencies on Meson

2. MCTP network ID - Plans to map index based network ID to NetworkID specified in specification(UUID format)
Reference: [Kernel - Networks referenced by index rather than UUID](https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md#networks-referenced-by-index-rather-than-uuid)

Arun: Currently Network ID implementation is different in kernel compared to the one provided by spec which is based on UUID. what is the plan to map both ?
Jermy: Not sure on the requirements though
Arun: example: when BMC acts as an endpoint or a bridge, and say pldmd works on multiple networks and needs to know on which network this eid corresponds to. In current kernel implementation I dont think we are handling this part.
Jermy: mctpd needs to know whether to generate or query network ID. We can integrate this into our requirement.
Arun: Current implementation assumes we are the top most bus owner?
Jermy: yes
Arun: Current implementation doesnt handle bmc as endPoint, correct?
Jermy: Yes that is correct. We can work on this if we have the requirements. Do we have any need for that ?
Arun: yes we were looking for this part
Jermy: It will be handy if we get some document/mail as reference
Sumanth: On PCIe network we are endpoint. So we are not generating the NetworkID. And say we need to act as bridge and bridge packets with smbus network which is considered under the same network.
Jermy: yes. We need some additional work when we are the endpoints
Tom: In multinetwork case do we need to have 1 control daemon or more ?
Jermy: 1 dameon. But it needs to know whether to assign eids or get eids.

3. Plans for handling multiple MCTP networks in PLDM
 Reference: 
     https://gerrit.openbmc.org/c/openbmc/pldm/+/51443/30/platform-mc/manager.hpp#55 
     https://gerrit.openbmc.org/c/openbmc/pldm/+/51184/23/requester/mctp_endpoint_discovery.cpp#74 

Arun: Currently in Gilbert's changes, EIDs are used as an identifier. With multiple MCTP networks, EIDs can be duplicate. We can have UUID along with EID as a identifier. But, some devices may not support UUID. Hence having Network ID along with EID and TID could be a solution. But as per PLDM specification TIDs should be unique 
Tom: TID can act as a identifier where Naveen is coming up with D-Bus objects for the same. When we move to kernel sockets we can go with Net ID approach.
Jermy: TIDs are unique across busses/networks ?
Tom: I dont think so
Arun: As per the spec it TID needs to be unique across busses
Tom: BMC can set the TID but it's an optional command. There can be devices which reports TIDs but doesn’t support setTID. 
Sumanth: Virtual TID can be used. The use case for this comes in pldm eventing.
Tom: Yes, having TID is a plus. We need virtual TID for NCSI.

In agreement to use unique TIDs in pldmd. Virtual TIDs will be used for devices which doesn't support SetTID.

4. nvme-mi daemon in upstream
Arun: Do we have any plans for having NVMe daemon on Upstream?
Jermy: Google engineers pushed a design on this and the discussions are happening.
Arun: Can you please share the link ?
Jermy: https://gerrit.openbmc.org/c/openbmc/docs/+/53809

Minutes 08 August 2022 - Cancelled due to long weekend(Bangalore)

Minutes 25 July 2022 - Cancelled

Minutes 11 July 2022

Attendees:

  • Intel - Arun, Sumanth, Rajasekhar, Vikash, Ananth, Anjali, Gokul
  • NVIDIA - Tom
  • HCL - Naveen Mosesss
  • Kumar
Opens:
Discuss about NCSI device readiness - https://gerrit.openbmc.org/c/openbmc/docs/+/47519
Tom: Propose a D-Bus interface with needed socket info. pldmd can monitor the same for device readiness. With this pldmd doesn't need to wait for NCSI device to come up and also avoid having JSON configuration in pldmd.
Arun: Also, D-Bus interface can be removed or property can be updated when the device goes offline due to some reason like FWUP
Naveen: In agreement with the comments and will be proposing new D-Bus interfaces in phosphor-dbus-interfaces.

Tom: Let's not modify existing SendRecive APIs in shared library, it may go invalid when MCTP moves to kernel implementation. Let's have a seperate library or file which handles NCSI specific SendReceive. The selection of library APIs can be done in pldmd based on the transport.
sumanth: From PMCI protocol perspective(SPDM,NCSI,NVMe-MI, PLDM) we may have multiple transport and multiple applications which may need this wrapper, thus having a seperate shared library might be good.
Tom: Our major transport today is MCTP and we dont have other usecase today. Let's seperate it out when the requirement comes
Sumanth: In agreement to write the code in a generic way and seperate it out later when required.
sumanth: How will be the tx and rx for the NCSI device?
Naveen: Will be creating a utility code using netlink socket library which can be used for sending and receiving pldm packets 

Minutes 27 June 2022

Attendees: Intel (Arun, Rajasekhar, Vikash, Iwona, Sai, Nidhin, Prithvi, Vasu) NVIDIA (Tom) HCL (Naveen Mosesss) Jeremy (Code Construct)

Agenda:
1. Naveen - PLDM transport layer wrapper design walkthrough - https://gerrit.openbmc.org/c/openbmc/docs/+/47519/13/designs/pldm-transport-layer-wrapper.md
Discussed PLDM wrapper design and need to address some final comments from Tom & Arun such as
* Define additional requirements for NCSI transport
* Capture PLDM FWUP related code/design changes required
* Capture how PLDMD will get to know the readiness of the NIC
* Naveen to check on Gilbert's PLDM sensor related changes and resolve conflicting designs

2. Jermey - NVMe-MI support in libnvme and demo
More info can be found at
https://github.com/linux-nvme/libnvme/
https://libnvme.readthedocs.io/
https://codeconstruct.com.au/docs/nvme-mi-with-libnvme/

Minutes 13 June 2022

Attendees: Intel (Arun, Rajasekhar, Vikash, Iwona, Sai, Nidhin, Prithvi) NVIDIA (Tom) Jeremy (Code Construct)

Opens:
1. PLDM transport layer wrapper (https://gerrit.openbmc.org/c/openbmc/docs/+/47519)
Tom: There are some portion of the design doc which are not fully clear.
Arun & Tom: Agree to core design - a transport abstract layer. But there is some overlap between then wrapper design doc and PLDM sensor monitoring design doc which needs clarity.
Tom: Let's have a walkthrough session from Naveen to finalize the doc and a re-review from Arun.

AR: Arun to re-review the design doc and Naveen to have a walkthrough session of design doc

2. Kernel MCTP driver
Tom: Did Intel tried to use Kernel MCTP driver?
Arun: Not yet. It is in our future plan.
Tom: which are the bindings Intel is interested in?
Arun: Intel is intrested in I2c/SMBus and PCIe. What about NVIDIA?
Tom: Same. I2C/SMBus and PCIe.
Arun: Did NVIDIA tried using it?
Tom: Not yet. But we are interested to use the same.
Arun: Please update if there is some progress.

3.NVMe-MI support in libnvmi
Jeremy: NVMe-MI support in libnvmi repo is merged. Please have a look and provide your comments if any. https://github.com/linux-nvme/libnvme/pull/76
Arun: Do we have a design doc for the same pushed to review?
Jeremy: This is not part of openbmc.
Arun: If others are also interested please explain on supported features added.
Tom: Good to have a knowledge sharing session.
Jeremy: Will prepare and present in next meeting.

Minutes 30 May 2022

Attendees: Intel (Arun, Rajasekhar, Sumanth, Vikash, Iwona, Sai) HCL (Naveen Mosesss) NVIDIA (Tom) Jeremy (Code Construct)

Agenda:
1. PLDM sensor naming - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252/13..18/designs/pldm-stack.md#b357
Arun: Proposed to include device location information in the sensor name along with sensor auxiliary name and entity auxiliary name. This information is required to uniquely identify the sensors on a platform
* Say we have a temperature sensor on an add in card, and if fan control need to identify the right fan and control the speed then location information(slot 1, slot 2 etc..) is required along with sensor name
Tom: Can we use the FRU information or association interface to solve this issue?
Arun: It might be possible to associate the sensors with FRU but
* If a platform has more than one identical add in cards connected, then it can result in duplicate sensor names appearing on the platform level sensor list.
* Does BMC web will be able to list multiple sensors with same sensor names? The redfish URIs for sensors should be unique.
Jeremy: It might not be a good idea to stuff all the information to the sensor name
Tom: Understand the issue and will re-visit possible solutions in future after checking the consumers/usecase of sensor list. It's too early to make the decision. For now will go with having TID in sensor name.
Arun: In agreement to continue discussion after checking the services which makes use of sensor list.
 
Opens:
1. Good to merge? https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519/ & https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252/
Arun: Overall, the proposal looks good
Tom: Proposal looks good. Expecting some initial patches to review
Naveen: To push the changes for review

2. Naveen: Current pldm service exits when mctp socket is not found on the platform. Need changes in pldm to look for other possible interfaces like NCSI and not to exit if mctp sockets are not found.
Jermey & Tom: In agreement with the same. pldm should look for NCSI as well and should not exit only with mctp socket not found

3. Arun: Is mctp driver is ready to use for pldm?
Jermey: MCTP over i2c changes are merged upstream. MCTP over PCIe is not yet done. 
Tom: Is there any timeline on which MCTP over PCIe will be implemented?
Jermey: Ok to work on the same if needed but need some device to test it on.
Tom: will check on the possible devices to test it with.

Minutes 16 May 2022

Attendees: Intel (Ananth, Arun, Rajasekhar, Sumanth, Vikas, Iwona) HCL (Naveen Mosesss)

Agenda:
1. Good to merge? https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519/ & https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252/
Follow up offline.
2. PLDM sensor naming - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252/13..18/designs/pldm-stack.md#b357
Moved to next week since PLDM maintainers(Deepak & Tom) are not able to attend meeting. 

Open:
Naveen: How can we check the mctp based pldm device implementation is working with new NCSI based implementation? Using Intel stack with qemu?
Sumanth: If it is in Intel stack then you could use mctp-emulator which mimics the mctp responses.
Naveen: Can LF openbmc mctp be tested with that?
Sumanth: No. it works with socket and emulator uses dbus based implementation.
Sumanth: Does your device support pldm over mctp, if yes you can use the same device to test it.
Naveen: Will check the same and see if it is possible.
Sumanth: Also, you can check with PLDM maintainers(Deepak & Tom) on the testing methods.

Minutes 18 April 2022

Agenda

  1. PLDM wrapper design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519
  2. PLDM sensor design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252

Attendees: Intel (Ananth, Arun, Gokul, Nidhin, Rajasekhar, Sumanth, Vikas) HCL (Naveen Mosesss) ARM (Gilbert Chen) NVIDIA (Tom)

1. PLDM wrapper design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519
Tom: how do you plan to trigger the discovery for pldm over ncsi?
Naveen: phosphor-network-manager uses entity-manager configuration to identify the device and expose it.
Sumanth: network reconfiguration callback is needed for non-responsive devices/after device reset/firmware update.
Tom: Proposed to use similar interface like mctp(where an mctp dbus-interfaces are used to detect device added/removed)
Naveen: Currnetly we have only static device and no dynamic endpoint support. Planning to start the implementation with the same.

AR: Naveen to update design doc with the proposal on how pldmd discover devices on NCSI over RBT and address unresolved comments

2. PLDM sensor design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252
AR: Gilbert to update desugn doc with terminus manager proposal(Terminus manager will implement PLDM base specification, handle device addition/removal, invoke PLDM type specific handlers based on supported PLDM types.)

Opens -
Sumanth: Sumanth to file github issues on message tag handling and configurable image path in pldm for tracking.

Minutes 21 March 2022

Cancelled and moved below topic to next meeting

  1. PLDM wrapper design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519
  2. PLDM sensor design - https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47252

Minutes 21 Feb 2022

##Agenda

1. pldmd MCTP device discovery
2. mctp kernel driver queries


Attendees: Sumanth, Arun, Iwona, Nidhin, Anjali, Rajashekar, Gokul (Intel)
Jeremy (Code Construct)
Naveen (HCL)
Andrew (IBM)
Tom (NVIDIA)



arj : we can make the entity manager to pass the configuration details to the driver/mctpd and make it work
sumanth: will review the mctpd and kernal patches and come back with queries


PLDM device discovery:
sumanth: We can have a terminus handler and based on the type supported we can call the corresponding handles(M&C/FWUP). Also, Need support for pldm type version checks
Sumanth: Even though the tid is not suported, we can have internal TIDs
Naveen: Talked about the terminus handler design and explained how it communicates to mctp/ncsi via wrapper
AR: Check with dmtf why setTID is optional in base spec.


Sumanth: How to advertize endpoint role from mctpd? Say if an endpoint discovered by another busowner need to expose its suported message type so that PLDM can communicate further.
jk-: Support is not implemented. Yet to be added.

##Agenda

  1. Jeremy - to introduce "mux holding" in kernel driver
  2. Discuss introduction of MCTP message tag and tag owner in demux daemon/pldmd

Minutes 24 Jan 2022

Sumanth - how can we introduce mux holding in kernel driver?
Jeremy - there are ways to do that using mctp neighbour tables - you can do hold the mux in both topologies - when there is mux behind mux, and also when there are multiple muxes on the same bus
Sumanth - I will reach out to you for the same.

Sumanth - We can introduce mctp message tag and tag owner on demux daemon - socket ABI will be broken though.
Andrew & Jeremy - better to use kernel infrastructure directly
Sumanth - Need the usecases to be satisfied - like the PLDM firmware update's mux holding usecases. Will check with Richard and get back to you.


Minutes 10 Jan 2022

##Agenda

1. Expose Message Tags and tag owner from libmctp
2. PLDM wrapper proposal
3. Handling i2c-muxes in kernel driver

Attendees: Sumanth, Arun, Iwona, Nidhin, Anjali (Intel)
Jeremy (Code Construct)
Naveen (HCL)
Andrew (IBM)

Sumanth: I have pushed a new libmctp API that is going to break RX API
compatibility - it introduces message tag and tag owner handling in libmctp.
Andrew - Yep I will have a look at it.

Sumanth: PLDM Wrapper proposal - needs some additional details in the design
document. I have left comments, but overall idea looks good.
Naveen: yes, I will address the comments and push again.
Sumanth: We can talk more on this topic when Deepak and Tom join.

Sumanth: For usecases such as PLDM firmware updates, the mux needs to be held in
its position to allow the device behind the mux to talk to BMCs. We can introduce a
"Reserve bandwidth" type of API that will allow us to "reserve bandwidth" for an endpoint.
Jeremy: Yes, we think that can be done with sockopt or netlink
Sumanth: Once we hold the mux, the other devices behind the mux could take a backseat.
Anyway, I was thinking to introduce a d-bus call in mctpd, which applications can invoke
in order to "reserve bandwidth". mctpd can translate this to a sockopt/netlink call.
Andrew: This would create another layer of indirection, what advantage does this bring?
Sumanth: Applications don't need to deal with physical layer details.
Andrew: Applications can directly make a sock/netlink call with just EID-network-id combo.
Kernel has the information necessary for it translate that to right method invocation.
Probably 90% of bindings would not need this anyway but for SMBus, it would translate to mux holding
logic
Sumanth: Agree, we can discuss further on discord.

No open queries.

Minutes 11/29/2021

Attendees: Sumanth, Arun, Iwona, Gokul, Anjali (Intel) Deepak, Tom (Nvidia) Jeremy (Code Construct) Naveen Moses (HCL)

MCTP update from Jeremey:

MCTP core code has been accepted in mainline linux and is expected to available with 5.16rc.
Serial binding is integrated, i2c binding  is in review. mctp daemon with more generic d-bus interface
is available in code construct (It doesn't have OpenBMC specific interface). Some code on
libnvme to support mctp interface has been sent.
Sumanth - Is I2c mux supported? Also, in PLDM firmware updates the i2c mux needs to be held so that
the device behind i2c mux can initiate communication
Jeremy - I2C muxes are supported in requester model; if device behind mux have to initiate the communication
there is no way to do it
Sumanth - We have control over when the devices will initiate communications - first the device
behind i2c mux will be put into update mode and then the device can start pulling the data from BMC
Jeremy - we could probably think of netlink interface to do it, but I need more details
Sumanth - I will discuss with Richard and get back.

PLDM Firmware update queries:

Sumanth - I don't see MCTP message tags and tag owner bits getting
supported; is there a plan to add support for this?
Deepak - yes we are aware of the shortcoming- we can either do it in
libmctp or could use kernel based approach which already supports
message tagging and tag owner bits
Sumanth - prefer moving to Kernel based approach

Sumanth - Watcher configuration for pldmd - today it uses /tmp/images
which is the image staging area (posted from bmcweb). however, if we have to do 
signature verification, then it can be potentially done by a different service.
Hope we can have a different staging area for pldmd
Deepak - it should be configurable in nature

Sumanth - Verify update behaviour: I skimmed through the code and it appears that
we are not taking any action on verify update failures.
Tom - I am congnizant of the fact and have work items to address it.

Sumanth - Gilbert Chen's sensor monitoring proposal looks good, I think we
can merge it
Deepak - yeah, I agree

Sumanth - Wrapper proposal discussion: the implementation needs to hide the 
mctp layer specifics in the wrapper
Deepak - yes, please think of the current MCTP implementation as one instantiation 
of the wrapper, I left the comments on the same
Naveen - I will address the comments

Agenda

PLDM transport wrapper from HCL

Minutes 10/18/2021

Attendees: Sumanth, Richard, Arun, Iwona, Nidhin, Ananth(Intel) Andrew(IBM) Velu, Naveen (HCL) Gilbert(ARM), Logananth, Kumar

Naveen presented on PLDM transport layer wrapper. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47519 
Deepak: Out of 2 option in the design doc, the implementation to integrate the wrapper to pldm looks good. Sumanth in agreement with the same.
Sumanth: It will be better to separate out the static PDR related discussion to Gilbert's PLDM design.
Naveen to update the doc's with the comments.
Deepak: where can be the NCSI wrapper should sit it. part of phosphor-network or pldm?
Richard: It can't be the part of phosphor-network. phosphor-network handles more of user side config like mac address, ip addresses etc.. Scope of NCSI wrapper will be more than that.
Naveen to update the documents with more details to come up to the decision.

Opens:
Sumanth: To load static PDRs, we need consider type of devices which doesn't support PLDM FRU, but IPMI FRU instead. Need to consider support for such devices as well.
Richard: The entity-manager can detect the devices based on FRU(IPMI/PLDM) and give the config file to PLDM. Then pldm can load the PDR config files and parse. But the json file should have the data in the PDR format and pldmd should parse the same to get details.
Sumanth & Gilbert: In agreement with the same.

Richard: Like to understand how much current upstream pldm is getting used now? Based on the effort needed I like to understand is it easy to port pldmd in Intel stack to upstream or the other way.
Deepak: Not sure how much the current stack is getting used across all users and forks. It is certainly being used by IBM and Nvidia. But if the intel-BMC stack can be pushed upstream, we can take measures to speed up the review process and merge faster.
Richard: Is it ok to push wrapper for upstream?
Deepak: Yes. Once the patches are available upstream we can test and see if something is breaking.

Minutes 10/04/2021

Attendees: Sumanth, Arun, Iwona, Nidhin, Richard, Anjali (Intel) Andrew(IBM) Velu, Naveen (HCL) Gilbert(ARM), Jayashankar, Logananth

Naveen presented on PLDM transport layer proposal. He will be pushing the design proposal for review.
The transport wrapper will provide consistent APIs for TX and RX of PLDM packets over multiple transports,
and abstracts the IPC mechanism from PLDM.

Open topic: How to handle devices which don't have PDRs?
Proposal 1: Devices without PDR can have static PDRs advertised by entity manager
Proposal 2: Have device specific static configurations in pldmd

Minutes 09/06/2021

Attendees: Sumanth, Arun, Iwona, Nidhin, Richard (Intel) Jeremy (Code Construct) Naveen, Velu (HCL) Deepak, Andrew(IBM) Tom(NVIDIA) Gilbert, Jayashankar, Logananth, Pavithra

Jeremy - mctp infrastructure discussion(https://github.com/CodeConstruct/openbmc-docs/blob/mctp/mctp-infrastructure.md)
Sumanth - Who does the EID pool management?
Jeremy - mctpd does the pool management. EID pool will be managed internally. Control interface can be used to trigger EID assignment.
Sumanth - How the fru data will trigger MCTP discovery?
Jeremy - Say NVMe devices exposes the device details through FRU, which can be queried by an NVMe daemon over smbus and it can trigger the MCTP discovery.
Deepak - How device discovery can be done in PCIe?
Richard - Explained Intel implementation of PCIe binding. When BMC acts as PCIe endpoint, it sends Get Routing Table Entry command to get other endpoint information.

Minutes 08/09/2021

Attendees: Sumanth, Arun, Iwona, Gokul, Mansi, Nidhin, Rajasekhar, Richard (Intel) Jeremy (Code Construct) Naveen, Velu (HCL) Manojkiran (IBM) Tom(NVIDIA) Gilbert, Jayashankar, Logananth, Pavithra

Sumanth: Intel PMCI code overview
Jeremy: No plan to have different daemon for each physical binding. MCTP wrapper can be optional.
Tom: How the MCTP daemon can take platform configurations?
Jeremy: Currently it doesn't have any configuration. But we can have configuration files or D-Bus.

Sumanth: Took recommendations and comments on Intel PMCI code convergence
libmctp (Intel supports- PCIe Binding, SMBus binding, MCTP Control messages) - MCTP Control commands can be up-streamed to libmctp for other projects
mctpd (Intel supports- Multiple MCTP daemon instances, Dynamic EID support, Supports Bus Owner & Endpoint roles) Jeremy - mctpd is already hosted. Yet to create recipes.
libpldm (Intel supports- PLDM Type 2, Type 4 and Type 5); Type 2, Type 4 already exists in community- Type 5 (FWUP) in review
pldmd (Intel supports- "Requester" functionalities & dynamic PLDM Terminus discovery; Type 2,4 and 5). Community has majorly "PLDM Responder". Align with MCTP Wrapper proposal to converge. Tom - PLDM FWU requester is being written down
pmci-launcher - Provides platform portability. Good to have in community

Agenda topic: PLDM Firmware updates - postponed to next meeting

Naveen - PLDM over NC-SI implementation explained
AR: Sumanth to create a tracking sheet to update PMCI implementation status

Minutes 07/12/2021

Attendees: Sumanth, Arun, Iwona, Smriti, Nidhin, Rajashekar, Richard (Intel) Tom (Nvidia) Jeremy (Code Construct) Velu, Naveen (HCL) Manojkiran, Pavithra (IBM) Gilbert


Sumanth: Does the support for i2c devices ready?
Jeremy: yes, Base is ready. Yet to test with a hardware
Sumanth: does the device behind the mux will be able to start a communication?
Jeremy: no, Only the bus owner will be able to hold the mux.
Sumanth: When can we expect message assembly and disassembly?
Jeremy: It's already added

Sumanth: How do we model the entity association using discovery agent?
Will be re-visiting the topic at later point.
Tom: pldm will need some sort of bus topology information, but not necessary to have association on MCTP D-Bus.
Sumanth: Another way could be obtaining the system topology information through Entity Manager
Tom: Yeah, we can think through and discuss in future meetings.

Naveen: How do we support NC-SI binding in OpenBMC?
Sumanth and Velu: It can supported via wrapper, this was discussed in earlier meetings.
Richard - Sumanth can propose the design on how you can use the transport "mapper" concept.
Sumanth - yes, for the MCTP transport, a PLDM terminus can be mapped to an EID, for a NC-SI/RBT transport it can be mapped
to Channel ID/package ID.
Velu - We will plan to discuss our usecase with community 
Sumanth - Yes we can focus on solving firmware update related problem in near future.

Minutes 06/28/2021

Attendees: Sumanth, Arun, Iwona, Mansi, Smriti, Nidhin, Rajashekar (Intel) Tom (Nvidia) Jeremy (Code Construct) Kumar (HCL) Manojkiran, Pavithra (IBM) Dharma, Srinivas, Gilbert, Jayashankar, Logananth, Naveen, Sagar, Selvamuthu

Opens: 
Jeremy: Need more details(documentation/ Spec) on Nvidia Mellanox card
Tom: Will check with team and try to get details

Sumanth: MCTP Wrapper detailed
Jeremy: Not interested to have a wrapper with hard dependency(usage of sdbusplus) to OpenBMC. But ok to have it for OpenBMC specific use case.
Planning to have control particle daemon written in C as part of generic utilities tools which can be used outside OpenBMC also.
Sumanth: Will come up with a design doc for review.

Minutes 06/14/2021

Attendees: Sumanth, Arun, Iwona, Mansi, Smriti, Gokul, Nidhin, Rajashekar (Intel) Tom (Nvidia) Jeremy (Code Construct) Kumar (HCL) Manojkiran, Pavithra (IBM) Srinivas, Gilbert, Jayashankar, Srinivas

Opens:
Iwona: MCTP security arrangements on kernel implementation.
Jeremy: Planning to add capability to define the packet permissions as a table
Iwona: How about in case of responder?
Jeremy: Will come up with a document to address security and will review the same.

Sumanth: Concern about NVMe-MI basic implementation going to dbus-sensors repo.
Will be continuing the discussion on gerrit.

Velumani: Can the PLDM sensors be monitored over redfish?
Tom: No, the community PLDM sensors are not exposed on redfish. The community implementation is basically responder flow. But there are some host sensors wich are exposed.
Sumanth: Intel implementation has the D-Bus exposure using Sensor.Value interface. Sumanth to give reference to implementation.

Velumani: we have requirement to update NIC-SI firmware through PLDM. Is the same redfish uri for the PLDM firmware update and BMC firmware update?
Sumanth/Tom: we have 2 PLDM firmware update design docs in review which explains the details.

Sumanth: MCTP D-Bus interfaces review
Tom: planning to give network ID and UUID along with EID to expose endpoint
Jeremy: The socket implementation needs network id and EID to identify the endpoint but the UUID can be an optional
Sumanth: Is this same as the spec defined network id which is optional. 
Jeremy: not exactly the same, its the network id needed to track the physical location of the device explained in kernel readme
Sumanth: Is it possible to have binding specific filtering?
Jeremy: interested to know the use case for the same.
Sumanth: We can have a separate discussion later when its needed.


Deepak: Detail on PLDM packaging for non PLDM type
Can certain UA implementation use the PLDM packaging to package non PLDM devices as well. Handling different packaging on seems difficult, which triggered this thought.
Sumanth: How the enumerations will handle
Sumanth: does the existing update mechanism move to PLDM (existing BIOS and BMC update mechanism)?
Deepak: If there are platforms without any PLDM capable device then there this may not be used
Sumanth: the proposal seems ok but to co-exist the same with previous update mechanisms in place will be tricky. How to address that?
Deepak: Planning to do it as an optional feature. PLDM daemon will be responsible to handle the other non PLDM type updates as well where it may not support PLDM.

Minutes 05/31/2021

Attendees: Sumanth, Arun, Iwona, Mansi, Smriti, Gokul, Nidhin (Intel) Tom (Nvidia) Jeremy ,Matt Johnston (Code Construct) Kumar (HCL) Manojkiran, Pavithra (IBM) Srinivas, Gilbert

PLDM FW design:
Rajasekar- Explained PLDM FWUP D-Bus interfaces proposed
Tom- Does the complete firmware update package will get unpacked by software-manager?
Sumanth - Only the minimal meta data info to identify the target and information like company signatures(if present) will be extracted in phosphor-software-manager and then the complete package will be handed over to PLDM daemon to proceed.
Tom- When having multiple target devices, how PLDM firmware update is handled if update is for specific targets or what if target is not specified?
Rajasekar- The user can use the inventory info exposed by software manager to specify the targets. If none are specified by user the PLDM daemon will update the image for all targets.

Kumar- Any code reference to use PLDM firmware update over NC-SI?
Sumanth- You can leverage the mctp-wrapper library in the Intel-BMC to bind to different transport layer keeping the PLDM code the same.

Minutes 05/17/2021

Attendees: Richard, Sumanth, Arun, Iwona (Intel) Tom (Nvidia) Jeremy Kumar

Jeremy - Update on MCTP kernel - Tree is up at the moment. Fragmentation is in kernel, I2C usage of kernel, other are WIP.
Testing is done over EVB board, and discussed about PCIe add-on card connected.
Approx timeline, expecting control & address assignment to be ready by Aug Mid (without bridging).

# MCTP D-Bus interface:
Sumanth: Thanked Tom for PLDM review. Looked at the D-Bus interface for MCTP. Please check Intel sent review for the MCTP D-Bus interface for MCTP. Also, what is the use case ? Sumanth discussed about protocol exposing the objects etc.
Discussed about the kernel implementation and exposure it to the application - (Already captured the same in the documents, hence not capturing it the minutes here).

# PLDM FW update:
Sumanth- Heard that Deepak is also aligning towards the Update-manager based FW update, or is there any change.
Tom - Wil check with Deepak and get back.
Sumanth - Will be pushing the flow as separate document in review. 

Minutes 04/19/2021

Attendees:

  • Richard, Sumanth, Arun, Smriti, Rajasekhar, Gokul (Intel)
  • Manoj (IBM)
  • Velu (HCL)
  • Tom, Deepak (Nvidia)
  • Joeri, Kumar
Opens - No opens

PLDM FWU:
Sumanth discussed bmcweb to phosphor-software-manager interactions and the D-Bus method to invoke a particular daemon for PLDM FWUP.

Sumanth - Intel has implemented only requester side of encode/decode APIs(without downstream device support in PLDM FWU- spec v1.1.0 ). Will be pushing the same to upstream.
Sumanth - Planning to define separate error codes(enums) for encode/decode APIs other than using PLDM error codes.
Tom/Deepak - In agreement with the modification. 
Sumanth - Will look into the efforts needed at pldmd side modifications for the same before making the change.

Agenda 04/12/2021 - Meeting cancelled due to holiday in BDC.

Agenda 04/05/2021 - Meeting cancelled due to holiday & conflict.

Minutes 3/22/2021

Attendees:

  • Richard, Sumanth, Iwona, Gokul, Nidhin, Smriti, Mansi (Intel)
  • Jeremy (CodeConstruct)
  • Andrew, Manoj, Pavithra, Jaypadanth (IBM)
  • Velu (HCL)
Opens - No Opens

Kernel implementation Plans:
Richard: Regarding the implementation plans and what binding is targeted immediatelf
Jeremey: Working in kernel coding now, and as first item will be covering self channel, followed by Serial (which will be easier to debug). Later need to add support for  LPC, I2C.
Richard: Intel is interested in I2C & PCIe binding, and can contribute / collaborate on the same. 

PLDM FWupdate:
Richard: Deepak sent message reg confict. So, if no one is having urgent need, then we can postpone this topic to next session.
Richard: As no concern expressed, postponing this topic to next week.

PLDM over RBT:
Sumanth: Presented the high level flow of how the PLDM daemon will separate the layer of PLDM over MCTP & PLDM over RBT. With TID (layer type field / bit), we can differentiate it, and accordingly do TID to MC-CH-ID (RBT) conversion or TID to EID mapping conversion. Same needs to be mapped during the TID assignment as well. 
Richard to Velu: What is the immediate requirement trying to address here & current progress
Velu: Currently we are working in daemon to do PLDM FW Update, but investigating an issue which makes us not to send more than 58 bytes of data. 
Richard: NC-SI must support ~1500 bytes of data. How the issue has been verified
Velu: Yes, it must support 1500 bytes, we confirmed this, because if we send Get Sensor reading command (which comes to 54 bytes), that is working. Because of this, we were not able to put the device in Fw Update mode. 
Richard: We are interested in PLDM over NC-SI interface. But, we won't be starting in another 2 months (at-least).
Velu: Ok. Will go through the code, and will ping for any queries
Richard; Sure.

Up-stream sync: 
Richard: Will be pushing the changes which we have on our branch to community repo starting from next week. 
Idea here is to push the changes to review first, and give 3 weeks for comments, based on that next step will be planned / scheduled.

Agenda 03/08/2021

Attendees:

  • Richard, Sumanth, Iwona, Gokul, Nidhin, Smriti, Mansi, Rajashekar (Intel)
  • Jeremy (CodeConstruct)
  • Deepak (NVidia)
  • Manoj, Sagar, Pavithra, Jaypadanth (IBM)
  • Velu, Kumar(HCL)
  • PLDM FWUP
  • MCTP Kernel design
Richard - Kernel design doc looks okay. We can merge the document and subsequent changes can be pushed as document update.
Jeremy - Patrick will look at this one. 
Richard - MCTP_ADDRESS_ANY has a value; when the first SET_EID/GET_EID is sent out, NULL EID can be sent out. 
Jeremy - Yes, NULL_EID can be associated with physical address and sent out. If the device responds with a EID also, the same socket can expose the same packet. MCTP Control is special in that way. 
Richard - If PLDM has to send messages to 3 devices, should the application open 3 sockets? 
Jeremy - Connect is for requester, bind is for responder. 
Richard - Message Tag expires if you send a message to a new EID?
Jeremy - You can retain message tag for old EID by defining a timeout. 
Richard - Concurrent messages to same EID ?
Jeremy - Not at socket level but Kernel supports interleaving (with different Message Tags). It is allowed for something like NVMe to send multiple replies to same request with same message tag. 

PLDM Firmware Update:
Sumanth to propose the edits as a separate patch on top of Deepak's patch.

Minutes 02/22/2021

Attendees:

  • Intel (Smriti, Sumanth, Raja Sekhar, Mansi, Arun, Gokul, Iwona, Richard)
  • Nvidia (Deepak)
  • IBM (Andrew)
  • Code Construct (Jeremy Kerr)
Opens: No opens
Agenda: 
MCTP kernel design
* Richard - MCTP needs to support NULL EID logic to communicate until the EIDs can be assigned by topmost bus owner. Also kernel MCTP design need to have option to support SPDM so that MCTP can send messages with or without SPDM encapsulation.
Jeremy - In agreement with same.

PLDM FWUP:
 Deepak - What are the issues that can happen if image manager and image updater is implemented by pldmd? 
 Richard - The images will be kept in separate staging. How the size of the image will be restricted or it will be cleaned later?
 Richard - Proposals to update the design.
 * single point(image updater) where multiple user can upload the image 
 * common place to manage multicomponent image(PLDM, non-PLDM etc..)
 * handling image signing 
 
AR's: 
* Richard/Sumanth to edit the FWUP doc as per the discussions and proposals.
* Deepak to have a look at libpldm code in Intel-BMC. If good Richard will try to upstream the code with less effort.

Provisional EID logic :
Richard - We are purging it, as we will directly move to Kernel and kernel design doesn't need Provisional EID

Minutes 02/08/2021

Attendees: Intel - Smriti, Sumanth, Raja Sekhar, Mansi, Arun, Gokul, Iwona, Richard Nvidia - Deepak, Tom Dell - Dharma HCL - Velu, Kumar, Pavithra, Sampa, Sagar, Jayashankar Padath

Open :
Richard - Regarding discord calls, legal is ok to use. Richard and Andrew can have  a dry run and we can move sync meetings to discord.
Might have to have a meeting in US friendly timezone.

Richard - Since Andrew is not present let us move routing related topic to next week.

Agenda - PLDM FWU design

Richard - Any reason why want bmcweb to talk to pldmd directly?
Deepak - bmcweb just needs to know about the d-bus api and shouldn't bother about the daemon implementing it. My concern with phosphor-software-manager is that it causes another layer and it causes a new d-bus method to pldmd. We can achieve all these by implementing the item updater and image manager both in pldmd.

Agenda 01/25/2021

  • MCTP routing/reserve bandwidth follow-up discussion : 15 mins
  • Sumanth: D-Bus interfaces for sensors and effecters : 20 mins
  • Opens from HCL: 5-10 mins

Minutes 01/25/2021

Attendees: Intel - Smriti, Sumanth, Raja Sekhar, Mansi, Arun, Nidhin, Gokul, Iwona IBM - Andrew, Tom, Sampa Nvidia - Deepak Dell - Dharma

Open -
1. Deepak - FRU related design doc update
Sumanth will push a patchset on top this
* MCTP routing/reserve bandwidth follow-up discussion : 15 mins
* Sumanth: D-Bus interfaces for sensors and effecters : 20 mins
* Opens from HCL on PLDM Firmware Update: 5-10 mins

D-Bus interfaces for PLDM sensors and effecters:
1. Numeric sensors : Re-use the standard phosphor-dbus-interfaces interfaces available today.
We have sensor.value, sensor.threshold (and additional interfaces to mark available/operational)
This can be used irrespective of polled v/s evented sensor
Sensor.type can be introduced ?

2. State Sensors: 
We do not have standard phosphor-dbus-interface today for state sensors. Do we need a standard
state sensor interface? What are community's usecases? 

3. Numeric Effecters:
4. State effecters:
No standard D-Bus interfaces exist today. We have internally defined D-Bus interfaces for these.

Deepak and Andrew: This is not something we envision, we can re-use the existing d-bus interfaces. Example - if a power operation effecter needs be exposed, it could be exposed directly using existing D_Bus interface. 

Minutes 01/11/2020

Attendees: Intel (Smriti, Sumanth, Iwona, Rajasekhar, Nidhin, Richard) IBM (Andrew, Tom) Nvidia (Deepak) Dell (Dharma) HCL(Kumar, Velu, Sathish, Priyatharshan)

Agenda: MCTP routing 
Richard: What is the plan to expose provisional EID to other applications when a flag is used to differentiate between normal EIDs and provisional EIDs.
Andrew: Upper layer applications should consider provisional EID as null EID.
Richard: How upper application will send back the response in above case?
Andrew: We need to use context to respond for the same.
Follow up discussion in upcoming meeting.

Richard & Tom: How to identify an effecter. Lets say there an effecter 'x' which control power, how to identify that effecter 'x' is the one which should be used to change the value. There should be something which explains the relation/association to identify the same with that of the PLDM device.
Will be revisiting on the topic at later point.

Opens:
HCL interested in PLDM Firmware update and sensors over NC-SI.
Richard: Status on current PLDM and MCTP implementation from intel
Velu: How the D-Bus interfaces for PLDM sensors are planned?
Arun: dbus-interfaces for IPMI sensors are reused in PLDM sensors. To identify the sensor names and other sensor details PDRs provided by PLDM device is used.
Velu: What if PDRs are not supported? Can i use entity-manager to advertise the configuration?
Richard: Recommended way is to expose static PDRs from a file or so if the device is not supporting PDRs.

WG meeting is cancelled till 1/11/2021 as there are plans for vacation. Next meeting is on 1/11/2021

Minutes 12/08/2020

Attendess: Intel (Smriti, Sumanth, Iwona, Rajasekhar, Mansi, Gokul, Nidhin, Richard) IBM (Andrew) Nvidia (Deepak)

Opens:
1. Moving to biweekly meeting - Deepak: Should be okay (other discussions can be through discord/mail list)
AR Richard - check can Intel use discord for community calls? Richard will check with legal team and get back (may take few weeks for this) - Not sure about the support for discord too.
Due to holidays, next meeting is postponed to 1/11/2021

Richard - Does nVidia have any new usecases for PLDM or priority feature support for PLDM?
Deepak - Plannning to get mctp over smbus working, probably next year we will look into PLDM requester (M&C, Firmware updates). Mostly on sensor monitoring and not much usecase for effecters.
Deepak - has anyone looked at emulated responses for BMC requester? This is to enable testing without the device side of the code being ready.
I2C stub exists today. A mock driver can be written which can send out fixed responses.
Richard - We have an MCTP emulator which mocks responses at MCTP layer level.
Andrew - You could transmit using a "mock binding". It is in the test suite of libmctp.

Agenda: Routing patchset
Richard - reviewed most of the routing infra patchset. Good with the overall model. 
Richard & Andrew - Discussed on the major comments in the patch-set (mostly to understand the usage direction or how it will be done in upcoming patchset). still need to revisit the Provisional EID concept patch. 
Richard - reference count usage makes the route entry holder to use the same (irrespective of validity), should not cause caching issue. So, better to use 1. direct usage - get & use don't hold logic, else 2. have reference count, but still refer the validity flag (so that caching won't be a problem). 
Andrew - Can't address it in current patchset. 
Richard - that should be fine. I hate introducing everything in single patchset - as long as it will be done in up-coming patchset should be fine.
Andrew - Will check and revert. 
Richard - Other clarification required is, in the entry we don't have a mechanism to tell whether EID is endpoint device or bridge etc. 
Andrew - For what purpose it may be needed. 
Richard - This is needed so that we will be able to indicate any routing table update to any bridge devices etc.
Andrew - Need to investigate on this. 



Meeting on 11/30/2020 stands cancelled. We will meet on 12/07/2020

Minutes 11/23/2020

Attendess: Intel (Smriti, Sumanth, Iwona, Rajasekhar, Arun, Mansi, Richard) IBM(Andrew, Deepak).

Sumanth: PLDM Firmware update overview
Andrew: How the pull model works when there is a mux in the path?
Sumanth: PLDM spec doesn't cover how it needs to be handled. But we are holding the mux until the update is complete.

Open: 
Deepak: What is the status of the MCTP/PLDM code on the Intel OpenBMC branch? What are the plans on upstreaming?
Richard: Our plan is to upstream but may not happen within end of this quarter.
The code in Intel OpenBMC is tested code. We will be able to send MCTP/PLDM commands in bus owner and endpoint with multiple devices.
Deepak: Have you tried pldm tool to issue commands?
Sumanth: No, we have APIs exposed by mctpd to send PLDM commands
Sumanth: Are you guys have any use case for PLDM through redfish ?
Deepak: Not currently but interested to have discussion.
Richard: We can have detailed discussion regarding the same in upcoming weeks.

Minutes 11/9/2020

Attendess: Intel (Smriti, Sumanth, Iwona, Rajasekhar, Mansi, Rashmi, Richard)
IBM(Andrew).
Andrew & Richard - Discussed about current MCTP routing patch status. Andrew addressed comments already and will be pushing updated patches this week. 
Sumanth presentation about PLDM FW update is postponed to next meeting, as Tom is on leave today, and decided to wait for his comments & feedback.
*Note was short meeting and decided to meet on 11/23/2020

Minutes 11/2/20

Attendees: Intel (Smriti, Sumanth, Arun, Iwona, Rajashekar, Mansi) IBM (Tom, Andrew)

Sumanth - Explained PLDM command flow for Base, Platform M&C and FRU.
Tom - Is BMC is the one assigns the TID?
Sumanth - Yes, BMC is the one who holds the TIDs.
Sumanth - IBM is supporting the static EID?
Tom- yes, For now IBM support static EIDs only.
Tom- Is the sensor polling frequency defined by PDR?
Sumanth - Yes, also we will have an upper threshold policy defined by BMC to consider physical interface limitation.
Sumanth - For numeric sensors how the events will be sent to BMC? For what value the events will be generated. How to configure it?
Tom - The device itself will indicate what are the event sources.
Tom - Proposed to use a GetNumericEffector before SetNumbericEffector command so that user will know what is the current value before performing a set operation.
Tom - IBM is currently not supporting SetFRU. What is the use case for SetFRU Record Table in case of Intel?
Sumanth - Can be used to update the device FRU during device manufacturing and also to update some OEM FRU data fields.

Meeting on 10/26/2020 is cancelled due to holiday. Next meeting will be on 11/2/2020

Minutes 10/19/20

Attendees: Intel (Smriti, Sumanth, Arun, Richard, Iwona, Rajashekar, Mansi) IBM (Deepak, Tom)

Deepak: Host FW need to drive some LED's. BMC can't directly control (exposed as effecters in Host)
Host FW will turn on LED and inform through the PLDM event. BMC must expose the same to the user (including events / Alert).

Arun: Initial flow for BMC as PLDM Subsytem flow (PLDM requester) which will go and discover other PLDM devices & how TID's will be assigned is discussed. 
Arun: Will depend on GetTerminusUID (based on the M & C support & GetTerminusUID support) command will be used and setTid will issue same TID if possible.
Deepak: What if the SetTID command is not supported
Arun & Richard: SetTID is mandatory if M&C type is supported (Basically needed when Event logic is supported), but if SetTID is not supported, then plan is to assign a VirtualTID(unique number, as we need to maintain the path with Tid) and expose the objects with that path (Say PLDM Fru device, FRU informaiton will exposed with that TID, which doesn't support SetTid). 
Rajasekhar: What if SetTID is supported and it returns error during set. 
Arun & Richard: Needs to treat that as error, and don't consider that as a device, as long as the error in unknown (Say it can return unsupported command - meaning, SetTID must not be issued, but any other error, we need to bail).
Tom: Purpose of SetEventLogRecevier command
Arun: Used to set the event receiver information details to the Terminus, so that it can use it for sending PlatformEventMessage.

Sumanth: Regarding the events based on state sensor. Does IBM already support Numeric sensor polling or changing the sensor value based on Event logging. 

Tom: Earlier there were mentioned about a problem for Event message, how that will be handled. 
Sumanth: for devices behind Mux, it can't send the message as MUX can't be switched by Add-in-card device
Richard: Adding to that, in that case of event, BMC will do PollforPlatformEventMessage instead of receiving the event message in async form.

Minutes 10/12/20

Attendees: Intel (Smriti, Sumanth, Arun, Richard, Iwona, Rajashekar) IBM (Tom, Andrew)

Tom - Explained thoughts about exposing host FRU and LED information out of band through PLDM daemon and bmcweb.
Sumanth- Who creates the D-Bus objects entry, entity-manager or pldmd?
Tom- pldm daemon create the objects to expose using bmcweb.
Sumanth - How are you plan to tie the inventory to LED?
Tom - Planning to use association interface to associate FRU and entity on D-Bus.
Richard - Explained current association interfaces in the OpenBMC and the constraints to represent PLM specific info using association(No direct way in OpenBMC currently to represent PLDM sensors/effectors through associations).

Open - How to identify the exposed sensor/effector is related to a specific PLDM device on redfish? Considering the use case of setting an effector value through redfish.
Tom& Richard - Continue the discussion next week with more details.

Sumanth - PLDM M&C design discussion
Tom - What are PLDM command table?
Sumanth - The base spec defines a command to identify which are the PLDM type specific commands supported by a PLDM device. Those information will be passed in command table to PLDM type specific init.
Tom- Did you consider using eventing instead of polling the sensor for value?
Richard/Sumanth - yes. Technically it is possible but we had some physical interface constraints to implement the same(say a mux in between BMC and an add in card)

Minutes 10/5/20

Attendees: Intel (Smriti, Sumanth, Arun, Richard, Iwona) IBM (Tom, Deepak)

Richard - First level PLDM design discussion (https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/37058/)
Tom - Is PLDM device manager is the one tracking addition of new device?
Richard - yes. Adding new device will create new endpoint device which will trigger the PLDM. Currently it is only based on EID and later will add support to other protocols like NC-SI also.
Deepak - What kind of information does entity-manager expose?
Richard - entity-manager exposes saying that a PCIe slot can support MCTP. Entity-manager depends on fru-device to expose the fru.
Deepak- Which layer is responsible for detecting presence of MCTP device?
Richard - MCTP layer will do the discovery over i2c probing and identify the presence of device. If present MCTP device will be exposed on D-Bus.
Tom - How MCTP daemon will filter the entity manager exposed devices if one PCIe slot is not populated?
Richard - entity manager say the a device is supported in PCIe slot 'x' but MCTP will identify if device is actually present or not.
Deepak - Where are the EPROM of the connected cards?
Richard - It is up to the design where the card has an EPROM or not(If there are IPMI FRU format and PLDM based FRU then it is a conflict of interest).
Deepak - How is the i2c connected to the add in card?
Richard - The i2c is connected to PCIe slot and from there to the add on card hardware. i2c is a part of the PCIe slot standard.
Tom- How the sensor is linked to slot?
Richard- Association is the one which tell to which particular slot the sensor is associated to.
Deepak - If RDE come into picture there are some part of the PLDM which gets replaced?
Richard- RDE cannot expose all the information required. Also some information can be exposed through RDE and PLDM. We need more discussion of that in DMTF before finalizing.
Deepak - What is the upstream planning on MCTP?
Richard - From October will start upstreaming but may get delayed by a month due to internal priorities.
Sumanth - PLDM is not specifying how PLDM FRU needs to be created on the baseboard. How we need to represent it?  
Richard - For IPMI the FRU is as part of a file system. In similar way we can have PLDM FRU.
Sumanth - what if there is only EPROM and no M&C support then how the FRU will be read? 
Richard - We are trying to move away from EPROM. With PMCI and SPDM we will be able to have secure communication between platform devices. The recommendation is EPROM should come below PLDM or an endpoint, so that only that corresponding endpoint can access that EPROM.

Minutes 9/28/20

Attendees: Intel (Smriti, Rajasekhar, Mansi, Arun, Richard, Iwona) IBM (Tom, Andrew, Deepak)

Opens topics -
Rajasekhar - Is there any reference for PLDM Firmware update linux driver mentioned in OpenBMC learning series? 
Deepak - https://www.kernel.org/doc/html/latest/driver-api/pldmfw/index.html 
https://www.phoronix.com/scan.php?page=news_item&px=Intel-PLDM-Firmware-Update-ICE 

Short meeting, as all members was busy on their work item. So, given back their time.

Minutes 9/21/20

Attendees: Intel (Smriti, Sumanth, Rajasekhar, Mansi, Arun, Richard) IBM (Tom, Andrew) Dell (Dharma)

Agenda topics - PLDM FRU
Richard- Explain PLDM FRU design
Entity manager uses the objects exposed by PLDM FRU to read FRU and expose the same on D-Bus.
Entity manager provides 2 options to expose the FRU info.
Option 1 - Expose the static info in the JSON file such as number of PCIe slots etc.(Implementation already present)
Option 2 - Expose information as per PDR exposed by PLDM daemon (e.g. Expose sensors of a PLDM device)

PLDM Platform M&C will expose the sensor information to D-Bus and redfish will expose the same.
But there are limitations in exposing the effectors of a PLDM device through redfish.
Open - Richard to check details on exposing the sensors through RDE or using D-Bus and redfish.

Rajashekar - Firmware Update basic design discussion
Tom- How the image is transferred from BMC web to PLDM?
Rajashekar - phosphor-software-manager will identify the PLDM firmware package using image header info and indicate it to the PLDM daemon
Tom- How to identify the target device?
Rajashekar - Inventory component info will be exposed to d-bus as part of the firmware update init.
Tom- How it is different from the FRU?
Richard - PLDM device can have multiple sub devices and can have component images for each. This will be exposed as results of FWU Inventory commands.
TOM- How to identify the target device if there are multiple PLDM devices?
Raja- Redfish exposes the target path and using which redfish can identify the particular PLDM device to update. Else by default all the devices will be updated.

Meeting on 9/14/20 is cancelled

Meeting on 9/7/20 is cancelled

Minutes 8/31/20

Attendees: Intel (Smriti, Sumanth, Mansi, Iwona, Richard) IBM(Deepak, Andrew) Dell (Dharma)

Open topics -
1) 

Agenda topics -
1) PLDM FRU
Mansi presented on high level PLDM Flow. Proposal is this -
/xyz/openbmc_project/pldm
|_/xyz/openbmc_project/pldm/<tid>
  |_/xyz/openbmc_project/pldm/<tid>/fru
     |_/xyz/openbmc_project/pldm/<tid>/fru/<fru-record-id>
         - IBM proposed PLDM FRU interface
         - Entity association interface
         - Set FRU interface

During discovery phase terminus IDs are represented as object paths and FRU record set identifiers will be used on the object path to represent each PLDM FRU record set in the FRU table.
These objects are going to expose the IBM proposed PLDM FRU interface, and the entity interface which associates Entity ID/Container ID with the FRU Record Set (obtained from FRU Record Set PDR).

Richard - We are also having other possible options to represent these information. We could also have Entity information in the object path itself. We are evaluating pros/cons of each of these methods.

Deepak - Can you send this one as design document update and we can review them?

Richard - yes.

Sumanth - Set FRU today has provided option only to rewrite the entire table even for a simple FRU field change. Is that something which needs to be addressed in the spec?

Deepak - How is it handled in IPMI ?

Richard - In IPMI it finally translates to I2C commands, we can set only certain sections of EEPROM using offsets.

Deepak - I suppose these questions can be posed to PMCI group and find out whether this was intentional.


Agenda 8/24/20

  • Day limited for OOB Remote BIOS configuration - discussion (Surya & Deepak).

Minutes 8/24/20

Attendees: Intel (Smriti, Sumanth, Mansi, Arun, Surya, Iwona, Rajashekar, Kuiying) IBM(Tom, Deepak) Dell (Pavan)

Open topics -
1) Rajashekar - rc values reuse PLDM_SUCCESS codes, might be confusing (https://github.com/openbmc/pldm/blob/master/libpldm/base.c#L184)
Deepak - yeah, I agree
Sumanth - Yeah we can propose different set of return codes.

Agenda topics -
1) BIOS Config manager
Kuiying - phosphor settingsd is used to handle persistent data.
Deepak - We can merge the current code, it is a good start. Next series can be on the persistent data. For the CI, Andrew Giessler can be POC.
From IBM, we are looking at Redfish stuff - there is a patch but needs update. 
Kuiying - Can look into Redfish next week.
Deepak - Concerns in phosphor-settingsd : there would be duplication of data on dbus since both RBC and phosphor-settingsd would host them.
Proposal is to handle RBC to handle its own persistent data. (libcereal)
Surya - next steps - Initial patch can be merged, IBM can look into persistent data handling, and Kuiying can look into bmcweb
Deepak and Tom - Agree

Minutes 8/17/20

Attendees: Intel (Arun, Sumanth, Rajashekar, Iwona, Mansi, Richard) IBM (Deepak, Tom, Andrew) Dell (Dharma, Pavan)

Sumanth - Any immediate requirement for the PLDM FWU from IBM?
Deepak- No plans to support in the immediate future.

Sumanth : Explaining PLDM Firmware Updates high level design.
1) Interface proposal
PLDMD to have objects with  FWU specific interface. 
Ex: /xyz/openbmc_project/pldm/<tid>/fwu
      Interface 1: xyz.openbmc_project.pldm.fwu.deviceIdentifiers
      Interface 2: xyz.openbmc_project.pldm.fwu.firmwareParameters
2) Reference implementation proposals

Deepak - Are the properties explained coming from the target devices?
Sumanth - yes, it will be exposed after executing the PLDM FWU inventory commands.
Deepak - Do we use the existing redfish interface to give the input image?
Sumanth - yes, we use the existing redfish interface and upload it to tmp folder. PLDMD will pick the file and proceed.
Deepak - Does the spec expect some check before the firmware update?
Sumanth - Target device need to do the verification check for the image.
Richard - Apart from the transferring of the image the verification should be done by the target device.
Tom- How PLDMD knows the target device?
Sumanth - The header will have the info to identify the target device.
Tom- Is PLDMD is just an agent to pass the image?
Richard - Yes. Like redfish, PLDMD will just act as an agent to pass the image to the target device.
Pavan - Does the PLDMD can directly send the packet to the target device?
Sumanth - No, there should be something like MCTP protocol to send the packet through physical interface.
Richard - PLDMD is responsible to construct the PLDM specific packet and pass it to the lower layer protocol like MCTP.
Richard - How much you are into OpenBmc from Dell perspective?
Pavan - I am responsible for PLDM, and DELL is in the adapting stage on OpenBMC.
Richard - Where does Dell stand with PLDM Monitoring and Control implementation?
Pavan- We implemented M&C for Dell proprietary BMC.

Agenda 8/10/20 No Meeting - Cancelled

Minutes 2/3/20 Attendees: Intel(Arun, Sumanth, Smriti, Rajashekar, Iwona, Mansi, Richard) IBM - Deepak, Tom, Andrew Dell - Dharma.

Richard - How are we tracking Instance ID?
Tom - EID is used to tack the instance ID
For BMC as requester, PLDM Daemon exposes Instance ID interface to generate Instance ID.
Richard - How many TID per EID. 
Tom - One, so we are really relying on EID.

Sumanth: How requester application tracks the instance ID? 
Tom: It directly interacts with the MCTP-Daemon and all application will wakes up, checks the packet and if matches proceeds further, else will wait for the packet again. 
Richard: How many PLDM application is planning to be maintained
Tom: Want to limit the application. Looking for PLDM daemon to monitor the D-Bus and accordingly update.
Want to march towards this, so that each application doesn't need to know, and can be concentrated by the PLDM Daemon.

Sumanth - Described the very high level flow for PLDM Requester flow. 
1. Abstraction required to hide the transport layer (Say PLDM message forwarded throug MCTP or NC-SI).
2. Mapper layer --> Responsible for converting TID to corresponding Unique address (EID / NC-SI address TBD).
3. Register handler for the PLDM types. This will call accordingly, based on the discovered devices
Tom: How / where you will track requester sequence of commands or when to call (say after PDR read etc.)
Sumanth: Basically, base layer will do first query based on the supported types, version etc., then after reading PDR etc, will call corresponding types handler(Which might have implemented the flow for other sub-types).
Richard: e.g. For FRU flow, once PLDM device is discovered, the M & C will do first query with PDR etc, and once it finds, device support PLDM Fru, it will call the FRU flow handler (along with the PDR), Fru flow handler will issue multiple commands in sequence and once FRU is available, will expose the FRU object (as per the D-Bus interface already merge). Entity manager can probe the same and accordingly expose other inventory items. 
Tom: what about the sensor flow for Eventing. Planning to implement only event based sensor. 
Richard: Need to support both, as PLDM device implementation can take any approach.
Richard: Have you envisioned how to expose the sensor in Redfish (Note: Some sensor's can't be exposed and effecters support not available in Redfish or not even needed to be exposed in redfish).

Minutes 7/27/20

Attendees: Intel(Sumanth, Smriti, Rajashekar, Iwona, Mansi, Richard) IBM - Deepak, Tom, Andrew Dell - Dharma.

  • PLDM
  • Communicate delay in Remote BIOS Configuration up-stream

Minutes 7/27/20

Richard: Agree with Andrew LOCAL type usage in the review, and corrected the review comments accordingly. This closes last week AR.
Richard & Andrew: Will discuss proivisional EID next week or in mail with pros & cons.

Richard - I see responder stack is present. Is requester available ?
Deepak - Don't have major use case for PLDM Requester. Code is being re-organised since Host-BMC usecase is one of its kind. It is moved so that if someone doesn't care about it, they can skip it. 
You can find requester usecases under Host-BMC directory. 
Richard - Do you plan to maintain multiple applications ?
Deepak - I'm not restrictive but there will be certain application on BMC which might not be hosted by pldmd. 
Richard - Do you mean user applications getting Instance IDs from pldmd and using demux to send out? or applications will ask pldmd to send the pldm message out ? and how are we going to protect sending out multiple messages to same TID ?
Deepak - Multiple termini can be used to implement the same.
Richard - Do you have plans to separate transport from pldmd ? (Ex: Sockets are used today, but tomorrow if have to support pldm over ncsi moving the transport to a wrapper might be advantageous). Wrapper will provide tx/rx apis.
Deepak - Do you plan to push a design / patch ?
Andrew - It will be useful to send a patch and send a documentation so that everyone knows whats going around.
Richard - Yes, we can do both.
Richard - Message Tags/TO is not used in pldmd. 
Sumanth/Andrew - this needs to be exposed by mctp layer, it is not there today but it needs to.
Richard - Do you plan to handle cards as well?
Deepak- Don't have it in plan for short term. 
Deepak - FRU is mostly from Host perspective. 
Sumanth - Intel would need FRU with BMC as requester, would look into contribution. 
Richard - What is status on PLDM File I/O ? 
Deepak - Planning to write specification after ballot. Usecase: To transfer opaque data. 
Sumanth - Does anyone plan to use PLDM FWU ?
Deepak/Dharma - This is long term plan.
Richard - Do you have performance related issues ?
Deepak - Not much with newer interfaces. PMCI can solve without application layers being affected since we can add newer physical bindings
Andrew - current version of lpc supports 8k tranfers. Current limitations comes from socket, you wouldn't be able to dump MBs of data on the socket.

Open - 1. Surya's update: Not able to push because of other priorities. Deepak can start pushing. 
2. US accessible timezones -  Richard to look into convenient times.

Minutes 7/20/20 Attendees: Intel(Sumanth, Smriti, Rajashekar, Iwona, Mansi, Richard) IBM - Deepak, Andrew Dell - Bala & Dharma.

1. Andrew & Richard: Discussed about the Endpoint types in the review. Richard & Andrew discussed about it, esp the LOCAL Endpoint types. As per the specification LOCAL refers to the Endpoint devices in the bus, which are not bridges. Andrew explained that ENDPOINT type was introduced to store and handle EID's of the BMC device for each port. 
Discussion still continued about the routing, esp about routing table management and response to the Resolve Endpoint ID & Get Routing Table entries. 
2. Provisional EID code (Andrew - under review) is discussed. Richard, asked about the management of the same, and when the provisional EID will be assigned and deleted back. 
Andrew mentioned that assignment happens when a packet with Source EID will be received or when we send with destination EID Null, and will be deleted when EID's are properly assigned. 
Richard mentioned that even after EID assignment, we need to handle the NULL EID, as even for properly assigned EID, we need to query the same using
GetEndpointID with Null EID, as we will not know, whether the device got reset and came back with static EID or with Null EID. In this way, the device will respond. It looks like we are going in a direction where alternate EID (along with the main EID management) for this provisional. Is it really require to add this much, or shall we just handle Null EID with private binding, which can be used to differentiate the device. 
We also need to make sure how the upper application (Like PLDM ) etc, will handle the same (Specification doesn't specify the same, but anyway with provisonal EID, it needs to check the flag with provisional EID concept). 
Note: Discussion on the same needs to be performed, perhaps with wider audience in the mail group as well. It is not yet resolved and documenting of pros & Cons will benefit. 

Next meeting plan is to discuss about the PLDM only. 

Attendees: Intel(Sumanth, Mansi, Rajashekar, Iwona, Smriti, Richard) IBM - Deepak, Tom, Andrew

MCTP Routing Table

Minutes 7/06/20

Opens - a) Meeting minutes needs to be reviewed
b) If more folks are interested capturing meeting minutes will be important. Volunteers can capture MM and publish in community mail (round robin). 
Deepak - needs to be the first agenda; can review and if approved can be published to the mailing list.

MCTP Routing Table:

Richard - Andrew can you explain the proposal so that we understand the routing table and provisional EID series correctly and then we can discuss.

Andrew - The problem we are trying to solve here is when NULL EIDs are used.  One approach is we can have seperate set of APIs to handle route of packets
before EID assignment and after EID assignment. But it would be nicer to have a single unified api. Provisional EIDs provide that option. For NULL EIDs
we can assign a provisional EID and mark it as provisional in the route table. The question is whether this approach works well for all cases of interest
- but it turns out that there can be a race condition for directly using the provisional EIDs. So the solution for that is we represent provisional 
IDs/real EIDs to upper layer, but for TX and RX of packets, we pass the physical address information to binding TX/RX handlers.

Richard - If I understand this right, we are passing physical address parameters between the core and binding, correct?
Andrew - Yes
Richard - Then why don't we extend provisional EID to 4 bytes and make sure that we capture physical address details there? 
Andrew - but we don't know how many bytes of physical address would be required. So the provisional EID will be internal to the device and will have
flags in the upper bits to represent whether the EID is provisional or not. TX handler would need the physical address information to pump the packet on
the wire. The route table will provide the necessary information for handling provisional EIDs - when we receive packet destined to provisional EID, we 
switch it to NULL EID destination. 
Richard - I have a different opinion - instead of putting efforts in mapping provisional EIDs to physcial address and making sure that they get removed
from route table when real EID is allocated, we can simply extend provisional EID bytes to hold physical address information. In case EIDs goes for an 
update how would applications know about the same ?
Andrew - In the 4th set of patch series I have introduced notification for route table update; on addition/removal of a route the registered callback
function will be called. Applications should not bother about physical address thus provisional EID should be sufficient enough. When applications are
sending packets through libmctp, core will get the packet first, and using the routing table, the right route for the packet is applied. The bus/binding
framecallback will fetch the physical address information and give it to the core. Core will use the bus_tx to transmit the packet out on the wire.

Richard - I will capture this discussion on mail thread and we can discuss pros and cons of the provisional EID (2 byte) versus full physical address+EID
(4 bytes/8 bytes) approach. 
  
Sumanth: How would PLDM Event receiver know the source EID if we are using provisional EIDs?
Richard / Andrew : Few of the things cannot be addressed before setting up a MCTP network. May be we need to investigate
whether modifying the pldm to accept provisional EIDs is acceptable.

Agenda 6/29/20 Redfish representation of PLDM data Review of routing table

Minutes 6/29

Opens: RBC design doc was merged. If Surya can address nitpicks on dbus interfaces and repo creation.

Review of routing table:
1) Multiple instances support : There might be a 3rd party process running the bridging. There can be bridge daemons update each other using notifications. 
2) Routing in case of multiple instances
Route table notification patch might glue things together. 
Might make a tagged release - to notify users of routing infra

Redfish representation of PLDM data: Might want to bring up the specifics and discuss next week

Agenda 6/22/20

  1. MCTP Physical medium specific information

Minutes 6/22

Opens - Deepak:Next PLDM item ? Richard: Redfish exposure flows need to be discussed, will send a document for review
BIOS update - +1'd. 

Andrew - Provisional EID discussion:
1) Andrew has pushed routing table related patches. You can register callbacks if route table updates. When we receive set EID, we can capture bus owner's details on route table (binding can update route table). If a relevant application is interested in knowing routing table update, it can register a callback. POC patches on general routing table in progress, needs feedback. 
Richard - we can have a look at that one. Related to provisional EID - are we using uint8_t ?
Andrew - we have couple of options without doing that, POC in progress.

> No PLDM topics

Richard: Redfish exposure of PLDM device : /redfish/v1/system/<add-in-card> 
Association with mother board can be done using "conaitned by"

Deepak: I don;t think there will be ever PLDM representation on Redfish schemas

Richard: We want to expose sensors say thermal sensors etc
Deepak - Redfish user need not be aware of PLDM. (Andrew agreed). 

Next week agenda - Redfish representation of PLDM data
Review of routing table

Agenda 6/15/20 (Note: Meeting will start 45 minutes late this week. 3:45 PM IST).

Minutes 6/15

Opens
MCTP - Control commands - Physical address - Null Endpoint ID handling.

Richard - can you please explain provisional EID?
Andrew - Avoid exposing physical addressing to libmctp consumers. These are specific to binding; thus we can avoid exposing it as a transport param. Provisional EIDs can provide local mapping to the devices that do not have EIDs assigned and once network is up and running we might not need it. There might be race conditions, need to think through. Mux in i2c binding can cause problems, but I think this needs to be handled by physical binding.
Richard - Using SetEID, we need to capture physical address to track the bus owner. 

Opens/Future agenda:
1) PLDM Firmware updates
2) Sumanth - How would we handle PLDM firmware updates for devices sitting behind an i2c-mux ? BMC would have to keep the mux communication channel open since PLDM firmware update is a pull model; i.e. device behind a mux needs to pull firmare update data. BMC needs to put the device into firmware update mode first and then device will start pulling the firmware update data. There is a need for PLDM to know about the physical mode the device is operating under.
Richard and Andrew - this needs to be beyond the mctp packet. Let's write down a detailed flow of how that is going to happen and then handle this.

Minutes 6/8/20


Attendees: Intel(Sumanth, Arun, Mansi, Przemek, Sandino, Smriti, Richard)
IBM - Deepak, Tom, Pavithra

No MCTP Topics today.
PLDM FRU openbmc-doc review:
Richard - We are okay with the proposed design
Deepak - Host firmware exposes capabilities but relying on eventing to capture FRU info. 
Richard - Will BMC listen to event receiver ? 
Deepak - Would check with host firmware and get back whether capabilities are advertised. Will push an update about PDR exchange flow. Would apply for Host-BMC communication. Flow might be based on bidirectional PLDM eventing for data exchange.  Envisioning BMC as primary PDR Repo. 
Richard - Will you load from Entity manager (host inventory configurations)? 
Deepak - Host firmware sends it to us. Might not be scalable, will be implementation choice. 
Richard - Entity manager can advertise sensors like TMP sensor which can be monitored by hwmon. But for PLDM, we can have PDRs downloaded from connected device and sensor can be exposed over d-bus which can  be picked by bmcweb. 
Deepak - BMC needs to set or get some values from host firmware and most cases don't need external exposure. Need entity manager to represent some objects like LEDs.
Richard - Then might not need Entity Manager
Deepak - EM will be required for building actual inventory, for PLDM sensors there will be accurate information in PDRs. Example - something like core info will not be part of PDRs thus will need EM and will rely on EM
Sumanth - we will need mix of both : EM to expose the inventory which is not covered by PDRs (Ex: Fan co-efficient)
Deepak - IBM will start writing code for PLDM FRU table. Probably we can have common code for the PLDM command flow (Get FRU table metadata and FRU table record) -  trigger points for collection of FRU may vary.
Richard - We plan to trigger the collection of FRU initially based on the capabilities advertised by the PLDM device; only in certain cases like FRU PDR update/ FRU table update, we can receive an event and retrigger FRU info collection
Sumanth - Agree
Deepak - I will have to check with Host firmware team regarding what they plan to expose as PLDM capabilities. 

Richard - I have couple of open points: 1) Regarding MCTP Message Tag usage : When we are responders we need to preserve the MCTP message tag sent out by the requester and respond back with the same message tag. 
2) PLDM being an application layer protocol can support multiple transport layers - PLDM over MCTP & PLDM over NC-SI. So in the long run we will have to abstract transport specific references inside application layer (example EID references). Okay to have PLDMD in a current state until we have a working solution.
Deepak - Yeah, currently we don't have NC-SI requirement but we can consider that for the long run
Richard - Another open regarding effecters - I don't see Redfish schema which support effecters in a straight forward fashion - we might have to use OEM action to initate effecters
Deepak - Effecter.value may not be standardized in the sense there are few effecters like LEDs which might be reusing phosphor-led interface
Richard - Are you planning to expose all effecters on Redfish ?
Deepak - Not all but some. 
Richard - Also, I see few issues in Redfish schemas to represent sensors; Thermal / power schema is straight forward however current related schema is related only to PDBs and is not applicable for sensors. 
Sumanth - Also what about the security ? The specification does not explicitly call out who gets to set effecter value. Probably we can assume only administrator role gets to set the value in Redfish
Richard - I will take an AR for the same

Surya and Deepak - discussed about RBC daemon design.

Minutes 6/1/20

Attendees: Intel(Sumanth, Arun, Mansi, Rajashekar, Iwona, Smriti, Richard)
IBM(Andrew)

EID 0 related discussion - Richard to send out mail today.
Also to send an invite to US folks.

Richard - Security related: should we handle EID-physical address verification?
Andrew - Specification says security is out of scope.
Richard - SPDM offers security. But bridging related might need security discussion.
Andrew - Recommendation is if you have different security requirements put them in different networks
Richard - How do we handle malicious behaviour? ex: spoofing of Bus Owner
Andrew - We can have Intel security or IBM security/or a common security policy. But this will not belong in libmctp
Richard - Are you looking at any security in your stack ?
Andrew - Check of EIDs in case of bridging is considered but not extensive check

Andrew - Merged Wiktor's code. Merged only transport related handling capability. 

## Agenda 6/1/20
* Opens
* PLDM sensor, effector & FRU Daemon - PLDM single daemon discussion
* Sync up on BIOS app
* Any feedback/questions on PLDM FRU D-Bus interfaces/design doc update?

* MCTP: Handling EID 0 (peer to peer communication using physical addressing mode)

Meeting on 5/25/2020 is cancelled due to BDC Holiday, please add any agenda below for next week.

Agenda 6/1/20

  • Opens
  • PLDM sensor, effector & FRU Daemon - PLDM single daemon discussion
  • Sync up on BIOS app
  • Any feedback/questions on PLDM FRU D-Bus interfaces/design doc update?

Meeting on 5/18/2020 was cancelled

Minutes 5/11/20

Attendees: Intel(Sumanth, Arun, Mansi, Richard, wiktor, Przemyslaw, Rajasekhar)
 IBM (Andrew, Deepak )
1. Meeting timing - To add US folks (once a month?)
Going to be difficult to accommodate everyone. 
Andrew: Early morning (Friday - Australian time 6 AM is the earliest one can acoomodate).
Bangalore:  (6 to 10:30)
Poland: (Early morning 6 AM to 10 PM).
Next step: Send out mail to know the interest & acceptable time slot.
2. MCTP - D-Bus interface review
Richard, Andrew & sumanth - Discussed about the pending review comments and next steps.
3. MCTP Null endpoint handling, Binding private data
Richard, Andrew, Przemyslaw & Sumanth: Will be difficult to handle multiple devices with EID 0, Andrew suggested to use
provisioned EID. Clarified that, will not work for multiple devices with EID0, and esp, when it goes for reset with dynamic address change. Also, it will be problematic to handle devices behind mux (in case of SMBus). Hence some kind of unique tracking id is required, and if that is to be used then better to use the binding private data, which can offer
solution to other stuff (say in case of devices behind mux, PLDM can request during firmware update not to starve the device behind particular mux to give priority etc.)
Next Steps: Send mail to community, with cases and start a discussion on the feedback.
3. PLDM PDR interface
Richard & Sumanth: Provided feedback. Looks ok to have PDR interface for effecter in D-Bus, but need to understand what we are planning to return (better to capture what bytes of the PDR record, whether whole Table 89 / Table 90 of the DSP248). Also, what about entity instance, if instance is not specified then multiple table 89 is needed. Also, are we planning to return common header, if not can we assume record handle is not needed?
4. OOB BIOS Config --> Overal D-Bus interface looks good (need to address nit comments).
5. PLDM FRU. 
Deepak: Earlier discussion seems ok, ok to align with the same logic. Want to expose the FRU in the PLDM daemon and entity manager to expose the inventory.
Richard: That's the way currently it is used by regular FruDevice, Our plan is to extend the same to PLDM.FruDevice as well.
Deepak: Can we expose empty inventory object (i.e. Without any content there) without anything in exposes
Richard: That should be possible, we can expose the decorator.Asset alone as well. 

PLDM sensor, effector & FRU Daemon - PLDM single daemon discussion - Postponed to next week, due to time limit. Will be taken as first topic in next week agenda.

Minutes 5/4/20

Attendees: Intel(Sumanth, Arun, Mansi, Surya, Richard, Przemyslaw, Rajasekhar)
 IBM (Andrew, Tom, Deepak, Zaheed, Pavithra)

### Pending commit discussion (5 -10 min)
* MCTP D-Bus commit - Any questions
Andrew: will try to review this week(was busy with other items)
* MCTP Control commands handler - 
Andrew: will try to review this week(was busy with other items)
* Clang-format of lib-mctp?
Richard: Arun submitted clang-format patch. It would be better if it can be merged and getting it removed from clang-ignore files.
Andrew: Don't want to do it in now, which is why it was added in clang-ignore.
Richard: We are planning to update lot of existing files, and it will be a problem for us when it happens in few weeks.
We need to do the clang-format now, or else need to wait for more time say 6 to 8 weeks? 
Andrew: Ok to wait for the same.
Richard: Then we will abandon the patch.
of existing files, and hence better 
* D-Bus daemon co-exist ?
Richard: Earlier we asked this question, are we ok in exposing D-Bus based transmit & receive of MCTP packets along with socket based approach. In this way, we will be able to push our changes in up-stream without any major issues.
Andrew: Need to understand the same on case by case basis. Based on the review only will be able to make the call.
Richard: But are we ok in allowing D-Bus based Tx/rx to exist together in that repo? 
Andrew: Don't want to expose the same, as people may start using that. Also, it will distrupt/delay the plan for kernel based solution (socket).
Richard: We will maintain it in downstream itself then (which still can be accessed using https://github.com/Intel-BMC/openbmc).
* Any other opens in MCTP.
Andrew: Any questions on the socket based response mail.
Richrad & Sumanth: We still have queries, but better to track the same in the kernel based design document, rather than in the discussion as that will give better understanding etc.
Andrew: Will try to push the same in few weeks. Discussed with Jeremy, and we will add Network id too along with the EID.
Sumanth: What about Msg Tag, need to add that one also as it is required in response packet
Richard: Do we need Msg Tag in response. i.e. Do we need to track other Message types as request & Response other than MCTP Control commands. Basically, PLDM can exist without MCTP too, in that MsgTag is not needed in the response and we don't track anything in PLDM with Msg Tag (Only source address is used, in case of MCTP, it will be EID).
Andrew & Sumanth: It's better to track the same. Andrew planning to expose TagOwner+messageTag fields.

### PDR interfaces review
Sumanth: What's the purpose of exposing the PDR D-Bus interface. Trying to understand the usage.
Deepak: Even I am not clear, asked Pavithra to update the same, we can discuss the same in the review.

PLDM question: 
Deepak & Richard: Discussed about how FruDevice and the inventory are exposed. In general.
Entity-manager will expose the inventory objects, but will probe the FruDevice (In this case, it will be probing both IPMI Fru & PLDM Fru). Plan is to use the Entity-manager itself to expose the inventory. Entity-manager will expose the devices based on the path, so we will be able to determine who owns what (through path name & association).
Deepak: Ok.

### OOB (15 min)
* Remote BIOS Configuration design
Deepak, Surya: Discussed about the removal of GetAll/SetAllBaseAttributes. Deepak suggested to use D-Bus properties (regular) Get & Set property, and expose the baseAttribute as single property?
Surya: Will update the document and send it out.

Minutes 4/27/20

Attendees: Intel(Sumanth, Arun, Mansi, Surya, Richard, Przemyslaw, Rajasekhar)
 IBM (Andrew, Tom, Deepak, Zaheed, Pavithra)

### Pending commit discussion (5 -10 min)
* MCTP D-Bus commit - Any questions
Richard: updated (removed send method & receive signal related D-Bus and submitted the patch). This must be in common
what we agree earlier.
Andrew: Will review it.
* MCTP Control commands handler
Richard: How about extending rx_handler (available today), and use that as single entry point (i..e handle the control commands, and regular message in rx_handler() iteself, extend with another argument for rx_handler() which will identify the same)?
Andrew: Will check the comment in the review and come back.
* Any opens in MCTP.
Richard: Gone through the mail with Sumanth & you, overall Netlink seems to a solution. But will wait for your documentation
Andrew: Sumanth, any further questions on the response
Sumanth: Still need clarification, but will wait for the documentation for better productivity.

Richard: Andrew, we are ok with control commands added in libcoremctp as helper function right? so whoever needs
can use the same to handle it. Will request to push a sample one, and let us know your feedback
Andrew: Sure, will review the same, but on high level look OK to me.

### OOB (15 - 20 min)
* Remote BIOS Configuration design
Surya, Deepak & Richard: Discussion happened on Patrick & Richards comment.
Few things agreed
1. Make sure RBC Daemon is independent of interface specific data & interface specific validation. It must handle general
BIOS Config & it's validation
2. RBC daemon D-Bus interface (esp the data types), must be defined. Need to make sure, it provides interface to view
difference in version, update configuration from BIOS, get / set user updated values etc.
3. Discussed about the fd usage instead of sending the whole data through D-Bus (decision was to first define regular D-Bus interface, and if there is too much delay, then it can be converted as fd).
4. Surya & Deepak will work on defining the new D-Bus API.

### PLDM
* PLDM sensor, effector & FRU Daemon 
Richard & Deepak: General discussion.

Richard: How to segregate regular messages with MCTP on a physical interface or as of today the physical interface is used only for MCTP Purpose?
Deepak: We are handling only one type as of now. Need to check with Andrew
Richard: Topic moved to next week


MCTP Socket Interfaces

Here are few questions for socket based implementation – 

Bus Owner / Bridging / Endpoint roles:
The current demux-daemon supports only static EIDs. How do we extend ‘Bus Owner”,
‘Endpoint’ and ‘Bridging Device’ concepts to demux-daemon? Also, when the sockets
move to Kernel, what would be the way for a user to configure a certain physical
binding in “Bus Owner” mode and another binding in “Endpoint” mode ? We will have cases
where BMC will be Bus Owner on a certain bus and Endpoint on another bus simultaneously.

Multiple MCTP Daemon instantiations:

The rate of transmission and reception of MCTP messages will be limited by the
underlying physical binding. Having one instance of MCTP transport
interface per physical port would speed up the TX and RX. How can
this be achieved in demux daemon? And how would this be addressed
in Kernel based sockets ? How can a user specify the physical bindings
he/she is going to need and instances for the same ?
	
Support for upper layer protocols:
In Intel’s usecases, most of the upper layer protocols like PLDM/Intel Vendor
Defined Messaging Type/SPDM etc. are going to be “Requesters” i.e. they are going
to send out request packets to a connected device on the platform (ex: Add-In Cards)
using MCTP. These protocols will not have prior knowledge about
the EIDs and thus need a way to query the existing EIDs and the
message types supported by the EIDs from the MCTP layer in order
to start their communication. The D-Bus proposal handles this by
creating D-Bus objects for the EIDs. How would we achieve the
same in demux daemon ? How would Kernel based sockets handle this ?
	
Discovery of MCTP capable devices:

We would need to modify the demux-daemon to cater for the discovery mechanisms.
When BMC acts as a Bus Owner, it would have to go ahead and discover other
end points on the bus and this discovery mechanism varies according to the bus,
and the role: For example: How a PCIe device discovers other endpoints is totally
different from how a SMBus device would do. Similarly, how BMC as PCIe bus owner
would discover other endpoints (Endpoint Discovery control commands) is different
from how BMC as PCIe endpoint would discover other endpoints(Get Routing Table update).
And discovered endpoints need to have a representation (ex: D-Bus objects) so that upper
layer protocols can discover them. How would this be handled in demux daemon/Kernel approach ?
	
Control commands:

Most control commands couple tightly with the binding and mctp layer itself; for example,
when Set EID is used by the BMC to allocate EID to another device, it needs to use
Special EID 0 + physical address of the device. Get EID command needs to return
binding specific information as a part of its response. Get UUID command needs to
return same UUID across all physical bindings. And so on. Thus how would control
commands be handled in demux daemon? How would it look like when Kernel based
sockets are introduced ?

Agenda 4/20/20

Meeting postponed to next week slot

  • D-Bus any other clarifications
  • control commands - revisit
  • PLDM sensor, effector & FRU Daemon - continuation from last week.
  • FRU Write up discussion - Deepak
  • Remote BIOS Configuration design

Offline questions (Place holder to get answer, when you will not be able to join PMCI WG. Will try to sync in IRC, mail, separate call with you, and try to get answers to you).

Minutes 4/13/20

Attendees: Intel(Sumanth, Rajasekhar, Mansi, Arun, Surya, Richard)
 IBM (Andrew, Tom, Deepak, Pavithra, Zaheed)

* D-Bus any other clarifications
Discussions continued, mainly in understanding whether any other approach is considered apart from socket. Also, for
notification what will be the plan for current scenario & kernel scenario. Also, asked about any state flow / design
document available for the kernel based scenario or current scenario with notification support?.
Andrew: In Kernel case, plan is to use NET_LINK, and for current, plan is to use D-Bus.
Richard: In that case can we have flag to control the Tx / Rx (from socket / D-Bus based approach), so that development
for others can co-exist. This also will reduce down-stream patch related stuff etc, as flag can be turned off in default.
Andrew: Need to think about it, as allowing it will cause others to make use of that from community point of it.
Richard: With flag, it will be easier to co-exist. Let us know.
Andrew: Will think & get back.
Sumanth: In a hypothetical scenario when we use demux-daemon, how do we introduce "Bus Owner" and "End Point" roles to the
bindings ? 
Andrew: You can have a separate daemon which handles all the control commands and subscribes to the demux-daemon. However
this cannot handle and binding specific data for the control commands. In that case, you can modify demux-daemon to handle
all the control commands.
Sumanth: We would need to modify a lot to the demux-daemon to cater for the discovery mechanisms. When BMC acts as a Bus
Owner, it would have to go ahead and discover other end points on the bus and this discovery mechanism varies according to
the bus, and the role: For example: How a PCIe device discovers other endpoints is totally different from how a SMBus
device would do. Similarly, how BMC as PCIe bus owner would discover other endpoints (Endpoint Discovery control commands)
is different from how BMC as PCIe endpoint would discover other endpoints(Get Routing Table update). And discovered
endpoints need to have corresponding objects on D-Bus
Andrew: As discussed earlier, this will be part of out of band notification, we can have demux-daemon having the
corresponding objects
Sumanth: Having just out of band notification might not work out for us, there needs be a flow defined for how the
discovery will happen and represent on the discovered devices on D-Bus. The background for this discussion is that most of
our upper layer applications like PLDM etc are going to be Requesters by nature. The applications do not have prior
knowledge of what EndPoints are available on the bus and what are their supported MCTP Message Types. So the MCTP layer
should provide a way for the upper layers to query about the endpoints available and their MCTP capability(the MCTP
capability of the device needs to be found out by sending Get Supported MCTP Types control message). The control commands,
thus should not be viewed as standalone commands but we would need a flow of using these control commands to present
meaningful information to the upper layers in the PMCI stack.
Andrew: Why don't you summarize this discussion and send it out on the community mail? That can be more productive.
Sumanth: Alright.

Deepak and Surya: Had a quick sync on PLDM BIOS Configuration related topics (2-3 minutes). 

* control commands - revisit 
Richard: Earlier based on our discussion we decided to handle the control commands through core-mctp, but there commands, which requires some binding specific information. Now, the question is do we need control_rx and regular rx, instead if we change the regular rx (to accept parm of control message or not), then with helper function alone in core mctp lib, rest can be handled in the daemon itself? (Anyway, current code just call the control_rx, so we can remove the same).
Andrew: Can you add the comment in the review, need to think and get back to that.

* PLDM sensor, effector & FRU Daemon - continuation from last week.
* FRU Write up discussion - Deepak
* Remote BIOS Configuration design


Minutes 4/6/20

Attendees: Intel(Smriti, Sumanth, Przemyslaw, Rajasekhar, Mansi, Arun, Surya, Richard, Iwona, Wiktor )
 IBM (Andrew, Jeffery, Tom,)

* Design (usage of D-Bus) - Discussion with Jeremy
Major discussions happened between Jeremy, Andrew, Richard & Sumanth. Capturing the highlights
Jeremy: Expressed concerns over not using the socket based approach, and highlighted that it may end up never aligning with socket based approach. Expressed interest in identifying the gaps and correcting the same, so that socket based
approach will be single solution in the community.

Richard: Current socket based solution doesn't offer notification mechanism for device property change / devices discovered etc. Hence D-Bus based logic need to be used for that. For MCTP tx/rx current socket differentiates things by sending struct (to identify eid etc), but our requirements needs changes to the code, as we will have multiple networks under bmc and single network across bmc. Also, we want to run single instance for each physical binding medium, and don't want to run one daemon for all physical medium. Also, we want all upper application to discover the underlying MCTP daemon dynamically etc. Hence to start with we will be doing tx/rx in D-Bus itself, we will come back later, as our first is to make the upper layer development a possible one. 
Note: Our ultimate goal is to align with proper socket based approach (so that kernel can be supported) along with notification support.

All: Discussion happened over why can't we use D-Bus based stuff, for notifications and socket based solution
for TX/RX. Andrew / Jeremy was ok to add Network ID along with EID, to know the differentiation, etc, and having named socket, so that multiple instance can co-exit.

Richard & Sumanth: Still don't want to make all those changes, as we still need to think well and align with the socket based approach. Any immediate solution to socket based approach, will hamper our upper layer development. Reiterated that we want to come to socket based approach as we expect it will half the time (in theory), as it is will be peer to peer. But don't want to start as we have certain things which require changes to the existing socket based approach, so we will revisit and align with the socket developement in few months.

Sumanth: Demux daemon doesn't provide the capability to be bus owner on a particular network and be an endpoint in another network.
Jeremy: Create a control command daemon to connect to the demux daemon and handle.

Jeremy: Don't want the code to be uploaded in the utils folder for the libmctp, as it will show 2 possible solution.
Richard: We can maintain in our repo and will be available through https://github.com/Intel-BMC/openbmc

All the following pushed due to time constraints.
* D-Bus any other clarifications
* control commands - revisit 
* PLDM sensor, effector & FRU Daemon - continuation from last week.
* FRU Write up discussion - Deepak
* Remote BIOS Configuration design

Minutes 3/30/20

Attendees: Intel(Smriti, Sumanth, Przemyslaw, Rajasekhar, Mansi, Arun, Surya, Richard, Karol, Iwona )
 IBM (Deepak, Andrew, Tom, Zahed, Pavithra)

1. MCTP Design document -- clarification /discussion if any
Richard: Updated the statement, to represent entity-manager as an option, similar to configuration file read. 
Andrew: That sounds ok.
Richard: Diagrams, also updated by sumanth, please go through and let us any further comments. Plan is to convert the
diagram as ASCII flow sooner or later.
Andrew: will review it.
Richard: Showed initiate libmctp- usage (design flow diagram). Not yet done, but will try to do it tomorrow. Idea here
is to understand the design & make people ready for reviewing the code.

2. D-Bus interfaces
Reg Base.interface.yaml
Richard: Regarding MCTP.Base.interface.yaml. Agree to your comment regarding Base, we can rename it to a better one. But don't want to put it as MCTP.interface.yaml (which will convey as full MCTP interface which is not what this is covering). This is covering only the base methods which will be used in both EndPoint or BusOwner base objects.
Andrew: Can try to see a better name.

Reg Device paths
Richard - Device object path name. 
Need to address 3 types of cases:
1. Endpoints
2. Devices with multiple endpoints
3. Bridges

After discussion, final way to represent is
EndPoint devices will be represented as 
/xyz/openbmc_project/mctp/device/uuid/<xyz>   --> this one will represent the device information and in interface will
list the supported eids?
/xyz/openbmc_project/mctp/device/eid/<xyz>  --> Each endpoint will represent this object & provide information. UUID
will be represented as a property under this object. Doesn't require EID as a property, as it is already there in the
path.

Above is true even for bridge devices, but bridge devices will provide properties to identiy that it is a bridge device and behind which bridge device. so that it can be constructed. Even devices behind the bridge will represent the
interface to indicate that it is behind a bridge using properties.
It has been decided not to represent the bridge in the path or expose the supported devices behind the bridge under it's path, as when we have deep bridges (bridge behind bridge), the path construction will become tricky
Also, we need to define new interface for bridge devices discovered, which will expose the routing informations like EID's behind the bridge etc.
3. FRU Write up discussion - Deepak
Deepak: showed draft diagram of the PLDM FRU notification to the inventory manager
1. once event is received from the Host PLDM, it will read the PLDM Fru, and expose the D-Bus object in their Phosphor-inventory-manager
Richard: We are also thinking in the same angle, but we want to expose the FRU itself as a object, which Entity-manager
can probe and expose inventory objects as per the need.

4. PLDM sensor, effector & FRU Daemon - continuation from last week.
Moving to next week due to time
5. Remote BIOS Configuration design
Moving to next week due to time

Minutes 3/23/20

Attendees: Intel(Smiti, Sumanth, Wiktor, Mansi, Arun, Rashmi, Kuiying, Richard, Iwona, Rajasekhar), IBM (Deepak, Andrew, Tom, Zahed, Pavithra)

1. Handling control commands in libmctp (continuation of [this review](https://gerrit.openbmc-project.xyz/c/openbmc/libmctp/+/30330))
Andrew: Wiktor proposal is good enough, we can ratify some API flow, but in high level, have no issues
Richard: Which option you are ok for (there are 3 proposals in Wiktor's mail). I have even made some comment in the review. Basically want to make sure control commands are handled by the libary layer itself, and accordingly notified to binding / daemon as per the need. e.g for Get EID request, control layer can itself can handle the same, there is no need to forward the command to upper layers, whereas for Set EID request it needs to be notified to binding / daemon.
Basically want to have common helper for control commands, so that De-mux / D-Bus daemon can make use of the same code.
Andrew & Wiktor --> that should be ok
Wiktor --> Having a handler for each control command would be messy.
Richard --> No need to have handlers for every control command, but instead it will be one handler for all control commands, and accordingly, we will get it processed (i.e. common will be in core, binding specific will be in that handler, and anything to be notified to the upper layer will be in that level handler). 
Sumanth: What about request packet transmitted, how it will be handled. Say the response of the same must be received by the daemon
Andrew: Yes, the response packet of the control commands must be forward to the daemon, and should not be handled by this handlers
Richard: we should not treat the response as control commands, and must follow the same approach as we received packet other than control commands.

2. MCTP Design document -->
Andrew: Not gone through the design & the interfaces
Richard: Please review, and add your comments, will try to address. Trying to merge the same as it is there for some time.

3. PLDM sensor, Effector & FRU daemon - Continuation from last week
Deepak: Not overly opposed to your earlier proposal. Reg sensors / Effectors ? not able to write fru exchange for the
host write up.
Richard: I am also pending on the write-up for this design, will try to update the same this week. 
Deepak: Regarding the movement of entity-manager ? Not real soon, but will take some time.
Richard: Then are you fine with configuration file management, till it is moved to entity-manager.
Deepak: FRU Write up we can discuss on next week.

BIOS Configuration:
Deepak: Design document itself - made some comments
Surya: Addressed / replied the comments. Main reason for handling the OOB BIOS Configuration in OOB-Daemon is to have common approach between Redfish / PLDM etc.
Deepak: Specific to IBM systems, BMC notifying Host firmware about BIOS attribute change. Typically BIOS pick up the change in next boot? 
Surya: we support both immediate / delayed stuff. When there is update, it will notify the PLDM etc, so that it can be informed to the Host firmware

SIO-Mailbox / Scratch Pad:
Richard: Whether IBM uses any LPC mailbox / scratch pad register in the SIO Complex. Any plans to implement a daemon, so that these register values can be advertised as properties?
Andrew: We used earlier, but dropped due to security issue. You can check the kernel code, and try to up-stream?
Richard: We don't plan to use the same for any communication of secret information, but like a progress indicator etc. Planning to write a common daemon for mail box, scratch pad and eSPI reset (eSPI is not applicable to others), so checking the same.
 

Meeting on 3/16/20 is cancelled.

Minutes 3/9/20

Attendees: Intel(Smiti, Sumanth, Mansi, Arun, Richard, Iwona, Rajasekhar), IBM (Deepak, Andrew)
1. Testing methodologies used - Continuation from last week
Andrew: What we are testing
Richard: anything in core-mctp / medium mctp. As of now 
Andrew: dummy binding or
Andrew: Adding unit test for bindings, to do code coverage (with hooks). I can point to existing changes done and we can
have a look at it. Improvement on separation between core code & binding point of it (70% of code coverage done for libmctp (lpc)). D-Bus level testing should be treated as end to end test case verification.
Sumanth: Clarifications - Say adding control command, set EID, how to do the validation test.
Andrew: will point to existing testing infrastructure written. 
https://github.com/openbmc/libmctp/blob/master/tests/test_serial.c

2. PLDM sensor & Effector - Continuation from last week.
Options: 
1. PLDM daemon (i.e. PLDM daemon itself, will expose a sensor service, under which all PLDM discovered sensors will be exposed) --> From Intel we are aligning towards this one.
2. PLDM sensor daemon (i.e. instead of PLDM daemon itself, expose a separate daemon - Not finding much advantage when compared with #1 but we can assume that it is outside the PLDM, but will cause delay due to one extra hop).
3. HWMon / PSUSensor or other sensor (which will query from PLDM daemon).  (Problem with this option is all the existing
sensor code must be updated to handle the pldm based sensors, but it doesn't have any extra functionality for the temperature based sensor alone. (i.e. all sensors can be differentiated as threshold / non-threshold sensor types).
Richard & Deepak: Let's discuss this one again in next week (with pros & cons, after which send it out to community audience for feedback).

Deepak: Does intel require PLDM as responder? What about async events? Any plans to handle it?
Sumanth: not at this point of time.

3. PLDM FRU - probing and system inventory
Sumanth: After discovering PLDM Devices, we need to add PLDM fru to the system inventory? Any use case Deepak?
Deepak: We are doing this one today(Not for connected devices). Exposing the EEPROM of the Host firmware. Host firmware will read the EEPROM, and send it to BMC using PLDM. currently it is using phosphor-inventory manager, but for long term
solution will be switching to Entity manager.
Richard: still we will depend on #2 problem. 
Deepak: For Fru information, PLDM daemon can't be done, as Host will do the same using in-band IPMI. i.e. There are systems which will be exposing Host FRU using IPMI FRU & some classes systems using PLDM Fru. Inventory manager will depend on the same.
Richard: xyz.openbmc_project.FruDevice service (under entity-manager repo), will expose all the FRU information. Even IPMI ReadFRU / WriteFRU command depends on the same. Entity Manager probes this FRU device and exposes the inventory accordingly. Plan is to have xyz.openbmc_project.PLDM.FruDevice under PLDM Daemon which will expose the PLDM FRU, and need
to make sure entity manager can probe both & expose the inventory. Currently Entity manager exposes
Deepak: Host is powered on once (End user like to see full query even after BMC reboot). We depend on file configuration,
Entity-manager --> Entity( Motherboard), 
Deepak: IPMI FRU transfer / PLDM FRU transfer. EEPROM FRU is stored in OpenPower VPD (Currently Host firmware is doing the translation and converting it to IPMI FRU / PLDM FRU).
Deepak: DSP2048 (EntityAssociation PDR) --> 

Deepak: Inventory manager and Entity - manager flows are different. IBM not yet moved to Entity-manager. Will check how long it will take to move. Entity manager to know the presence of Host. 

Richard: Please review MCTP design document.
Surya: BIOS config - OOB design document updated please review.

Minutes 3/2/20

Attendees: Intel(Smiti, Sumanth, Mansi, Arun, Richard, Iwona, Surya), IBM (Deepak, Tom, Zahed)
Richard: Testing methodologies used (Unit test & review tested case)
Deepak: pldm tool can be executed 
pldm is requester. 
This tool will execute the parameter option requested, execute and get the response to the targeted responder.
pldm tool also uses libpldm for the encoding / decoding (So that we don't need to write a separate code for forming the packet, as it comes from libpldm).
Working with PMCI to form a common MCTP / PLDM tool to test. As of no tool for MCTP. 
Sumanth: Do we have a way to test the BMC Requester functionality? Because PLDM tool act like PLDM requester and tests the 
BMC Responder functionality, Any plan / Work to do the reverse.
Deepak: As of now, we don't have a tool to test the BMC requester functionality. 
Richard: Any plans to have a virtual medium, so that we can run both the requester & responder instance. Any plans
Deepak: As of today we don't test the PLDM / MCTP requester functionality, as the tool act like requester
Richard: What do you think about introducing the virtual medium and using 2 instances so that we can test both the
requester & responder functionality. E.g. to test both Set EID requester & responder. 
Deepak: Should be doable & i think better to do. Need to check with Andrew too (AR: To discuss in next week meeting). 
Sumanth: How to do the testing for the medium specific functionality ? Whether IBM has any methods. Whether it will be acceptable if we do in one board and assume other is also fine?
Richard: At this point of time, there is no conflict with the medium specific code, but frankly we need to figure out
the medium specific testing or run some CI to make sure things are not getting broken.
Deepak: Need to figure that one out.

2. PLDM daemon logic - sensor discussion
Deepak: Lot of other OpenBMC User level application, to query the PLDM daemon (say redfish to interact with PLDM daemon).
Richard: Today redfish, doesn't query based on hard-coded service name, instead it just queries on all services which exposes the Sensor.Value interface, hence if we implement pldm based sensor, redfish should be fine.
3 options
1. PLDM daemon (i.e. PLDM daemon itself, will expose a sensor service, under which all PLDM discovered sensors will be exposed).
2. PLDM sensor daemon (i.e. instead of PLDM daemon itself, expose a separate daemon - Not finding much advantage when compared with #1 but we can assume that it is outside the PLDM, but will cause delay due to one extra hop).
3. HWMon / PSUSensor or other sensor (which will query from PLDM daemon).  (Problem with this option is all the existing
sensor code must be updated to handle the pldm based sensors, but it doesn't have any extra functionality for the temperature based sensor alone. (i.e. all sensors can be differentiated as threshold / non-threshold sensor types).
Deepak: How about fan control alogithm in option 1 & 2.
Richard: Need to check the fan control algorithm, but should be simple to change to use service discovery instead of hard-coding the service type.
Sumanth: What about effectors? Whether PLDM daemon expose the set/get effector interface or some other daemon for redfish to set / get the effector value. 
Deepak: We want pldm to handle the mapping with redfish OpenBMC request to effector request. (i.e. Say Redfish want to power on the host, and if it is pldm effector, then pldm, must see the property update to RequestedHostTransition and accordingly update the needed effector).
Richard: Is that approach scalable. Why don't we rely on the separate daemon itself, today x86-power-control handles that
property, and accordingly, triggers the same using GPIO / i2c or whatever is required. Why can't it handle the effector set to the pldm?
Deepak: We are looking at json mapping, so it should be scalable in nature
Richard: Need to look at the reference code / example code for better understanding
Deepak: refer the example section in pldm repo.

Will continue discussion further on next meeting.

Minutes 2/24/2020

Attendees: Intel(Sumanth, Rajasekhar, Arun, Richard, Iwona), IBM (Andrew, Deepak, Tom)
1. IPMB & MCTP Over SMBus - co-working together (How about IPMI over KCS & MCTP Over KCS - co-working)
Andrew: Not reached the IPMB problem, but interested in your solution
For KCS using BT interface and for MCTP binding, using regular KCS (so not facing the problem yet).

2. MCTP design document & Interfaces - Discussions.
Richard: related to socket based approach, our ultimate goal is coming to socket, but not yet, as there is no standard way of device discovery in socket based approach. We will come to socket based approach, after a year or so.
Andrew: Is there any prototype for the proposed design & the D-Bus interface. If there is any, exposing the same
will get better. 
Richard: Sumanth has uploaded the design document which has picture which will give overview of the D-Bus interface
Andrew: Didn't had a look at the diagram, will look at it, probably it answers some of the questions.
Sumanth: Overview of the MCTP design & the D-Bus interface. Will upload the state diagram also.
Deepak: Won't D-Bus interface causes delay the transaction. Have you checked the timeout
Richard: Yes, D-Bus will cause some delay, but at the same time, we are running instance for physical medium, and hence multiple daemon will be able to transact in parallel, if medium supports it (which will not be possible, in direct library based approach). Planning to use fd, for larger payload to save time as well. In theory there shouldn't be major difference, as we will save time in other places. We have not done a testing of PLDM timing measurement at this point of time.
Iwona: Wrapper based query, so that application can work on both D-Bus & socket based approach.
Deepak: What about demux-daemon? Planning to consider demux-daemon with the wrapper for the socket & the D-Bus type.
Richard: At this point of time planning to keep separate the MCTP daemon & the demux-daemon, but need to have wrapper based library.

3. PLDM daemon logic - write-up discussion
(topic shifted to next week as we ran out of time.)

4. Few people in pacific time wants to join PMCI WG. Need to see convenient time or monthly once shall we rotate time convenient to US.
Richard: Please check and let me know the worst timing you can support. As few people in U.S are interested, we can host at-least monthly 1 meeting in US timing. 
Deepak: Planning to support Redfish schema for BIOS configuration
Richard: Yes, that's the plan
Deepak: Design document doesn't cover on the same. Can you also publish the work items, and if possible timing, so that
collaboration can be achieved. 
Richard: Will request surya to update the document. Yes, we need to do that, so that no two people do the same work.
May need a mechanism to do that? Do we used anything for this in the past.
Deepak: Kurt was using google docs or something, will check and revert on the same. 

Minutes 2/17/2020

Attendees: Intel (Sumanth, Raja Sekar, Richard, Iwona, Surya). IBM (Deepak, Andrew, Tom & Pavithra)
1. Repo for MCTP Daemon or shall we use libmctp folder (planning to rename libmctp to mctp / separate repo)?
Andrew: libmctp is designed to maintain for both host & BMC libmctp purpose.
Richard: Can we maintain both MCTP daemon & library now in libmctp repo, and later change?
Andrew: Let's start with different repo for the MCTP daemon (separate from libmctp), and revisit (if any requirement changes).
Richard: Ok.
Deepak: Already there is too many repo, do we really need one?
Andrew: Code base is not same (as libmctp will be used by non-BMC devices like host fw). So it's better to maintain separate one for the daemon (which will have OpenBMC specific interfaces).
Andrew, Richard & Deepak: Separate repo for MCTP daemon (OpenBMC related interface exposure)
Note: Will maintain binding in libmctp repo (PCIe vdm & SMBus binding).

2. MCTP design review --> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/28424/ (Please review offline, and
we can discuss it on next week call based on need).
Deepak: question regarding host f/w support, whether looking in re-using the MCTP/PLDM code re-use in Host F/W.
Richard: UEFI F/W will have it's own implementation of MCTP / PLDM, as it's having it's own standard way of writing, and there are many people who will be using it. Hence don't expect OpenBMC libMCTP to be re-used directly in UEFI F/W.

3. PLDM (Multiple application).
Richard: Earlier design shows Instance ID assignment as separate daemon (and multiple daemons for sub-functions), which uses library. Any reason for the same. How about maintaining PLDM sub-function in single daemon itself
Deepak: We want to avoid D-Bus calls, hence using libpldm directly in the application & using D-Bus API for instance ID assignment.
Richard: How about device discovery notification etc, how it can be processed, Also, how errors are handled, what if the one application which got instance id x crashes, & how instance id x+1 is allotted. What about out of packet error handling.
Deepak: Timeout happens when response is not recevied. Both sync & async calls track the response based on the instance id. Related to the single daemon usage, as long as it can handle the application, it should be fine. Let us know the proposal.
Richard: We will further discuss this in next week call, with small write-up.

4. Deepak: Quick sync-up on BIOS attributes. Can we discuss about it in this meeting, or only PMCI
Richard: This meeting is to specifically discuss about PMCI & Redfish eventing, but don't mind to discuss different topics at the end, if it helps. (Andrew, Iwona, sumanth & everybody else in agreement).
Deepak: Have few questions related to BIOS attributes, sent a mail
Surya: Will respond with answers to your question. Please review the design document in place
Deepak: Going through it, hope to complete in by this weekend.

Minutes 2/10/2020

Attendees - Intel (Sumanth, Raja Sekar, Wiktor, Mansi, Arun, Richard, Iwona, Smriti). IBM (Deepak, Andrew)

1. Socket based / D-Bus approach. Plans? Looking for Component communications, not only for BMC to Host (BIOS)
Andrew: Currently exploring socket based approach. Alerting mechanism is not there like D-Bus. 2 types based mechanism is explored (Netlink for eventing). Will be delayed due to other priority. Ok to go ahead with D-Bus model approach (which provides a way to switch to Socket based approach).
2. Lib Core MCTP --> C / C++  (If socket based logic, then C code is not needed right?) --> 
Andrew: Still want libMCTP in C for purpose of re-use. Ok to approach daemon in c++, with libmctp in C.
Richard: Daemon being C++ & libMCTP in C should be ok to start as many code can be reused.
Deepak: libpldm responder implemented in c, for the same reason.
3. What about smbus / PCIe (can we maintain C++)
Andrew: Preference is to have single library to include libMCTP & binding.
Richard: We can maintain separate binding library, will revisit the +/- and then come back (Should be ok to have single
library to include mctp, binding, control commands).
Deepak: What about long term?
Richard & Andrew: long term kernel based approach.

Feature based support

1. Bus owner / Device End point model ? 
Andrew: Root bus owner, bus owner & device endpoint all are needed (Other than D.E, not immediate).
Richard: Smbus B.O is needed, and PCIe will be D.E (Iwona confirmed).
2. Discover of devices in MCTP ?
Andrew: want to support, not immediately.
Richard: From Intel we will be implementing this in first place as our SMBus binding needs the same.
3. Dynamic EID / Static / Both ?
Andrew: Not in near future. 
Richard: SMBus binding, requires Dynamic EID allocation for the discovered devices.
4. Single Network (Top most Bus owner needed?)
Andrew: Top most bus owner needed.
Richard: Not in immediate future, Will be going ahead with Bus owner, with statically allocated EID Pool.
5. Routing / Bridging support
Andrew: General plans, not immediate
Richard: Not immediate
6. Rate query / limit support ? 
Andrew: having some performance issues, hence looking in to this to do BTU increased size.
Richard: Not immediate

LibMCTP

1. Planning to support multiple message support (Interleaving)? (Code seems to support)
Andrew: Yes. 
2. Device endpoint --> Planning to support ERROR_NOT_READY / ERROR_INVALID_DATA for unsupported types 
Andrew: Won't dropping won't be enough, 
Richard: will double check, thought we should return error.
3. Timeout --> Currently it is not handled ? Planning ? 
Andrew: yes, we need to support.
Richard: We needed this feature, as we are implementing SMBus as B.O.
#### Control Commands
1. No commands currently implemented. Needed ? We want to implement all Bus owner discovery etc.
Andrew: Yes, need to plan.
Richard: We need this, we can start on this then. 

Regarding Maintainership:

Richard: We will start contributing towards the daemon, SMBUS & PCIe VDM binding along with control commands. Need to add as reviewers in your contributions as well. Need to have one intel Maintainer
Andrew: Iwona is already in reviewer list, Richard can add himself as well. Once contribution started, we can add more
maintainers
Richard: That would be fine. Maintainers, can make sure, that it is ok by working together and bringing resolution to things which are not in agreement.
Clone this wiki locally