eBMC State Management - Timed Power On

[geissonator]

Need PLDM message defined for host to call and code on OpenBMC side to support it..

[vishwabmc]

Went through the existing implementation and had the discussion with Paul on the PHYP time management algorithm. We don't have the legacy RTIM implementation for time keeping now so need to get onto the new xyz/openbmc_project/Time.

Since we are dealing with Host Time here, we need to use xyz/openbmc_project/time/host/

---

The implementation MUST cater to these:

• Have a policy ( setting ) that the user can use to enable / disable TPO feature

  • Use xyz/openbmc_project/settings/ and introduce a setting

• Disable the TPO timer on encountering any error processing request

  • This would be internal to the application. Make the time as [0], so it won't fire any time.

• Power On the system on timer expiration

  • Post attempting, disable the TPO timer by writing [0]
  • Use Phosphor State Manager to do the PowerOn

• Provide APIs to Set and Get TPO timer values

  • These are PLDM commands and their implementations.

    • Back-end to support these

My current approach to this is ( good path ):

• OS will push the TPO request to PHYP ( Time since epoch )
  • PHYP will use a PLDM command to push it onto the BMC ( Need to identify what command can this be )
  • BMC PLDM layer will catch and call the handlers
  • Handler will invoke an API to a new stand-alone application that handles TPO request

The new standalone daemon:

[-] Case 1

• Will start a timer for the TPO value ( SetTimedPowerOn )
• Check what is the HOST TIME from the Dbus
• Run the timer if needed
• Fire the Power On post timer expiration if the conditions are met) [-] Conditions:
  • System is still BMC_READY --> This can be a systemd pre-req
  • Someone has not disabled the TPO policy
  • Current time is same as TPO time

[-] Case 2:

• Will return the currrent TPO timer value when requested
  • this would be to cater to GetTimedPowerOn value

[-] Case 3:

• Will set the current TPO timer into internal buffer
  • This would be to cater to SetTimedPowerOn value

[vishwabmc]

In discussion with PLDM folks, sending the "seconds since epoch" from PHYP is still possible and would be part of a PLDM numeric effector.. But such a code does not exist today and we need to implement.

@mine260309 is this something that your team would be interested in ?

[mine260309]

@vishwabmc Yes. However, it requires the hardware which is not available yet, so we could not really work on this task for now.

[vishwabmc]

Some reference materials for PLDM / MCTP:

https://github.com/openbmc/libmctp https://github.com/openbmc/pldm

[vishwabmc]

Could break each one of these into multiple stories:

• [ ] Implement a PLDM command/response that would handle an integer indicating a desire to do TPO or not. A Policy basically.

• [ ] Implement a PLDM command/response that would carry an integer value indicating the TPO value ( seconds since epoch )

• [ ] PLDM handler to invoke the TPO standalone daemon supplying the above data

• [ ] Implementation of TPO daemon that will:

  • handle above data
  • Trigger State Manager function as part of TPO timer expiration.

[mine260309]

Based on @vishwabmc 's detailed description, the tasks are divided into two parts:

• In PLDM, it could be implemented by new OEM command or numeric effecter PDR as @dkodihal 's suggestion.
  • ~Design and add new OEM command(s) for TPO~
  • ~Implement encoder/decoder of the OEM command(s) in libpldm~
  • ~Implement the responder in libpldmresponder~
  • Add PDR config for TPO
  • Implement SetNumericEffecter (or equivalent) command
• The TPO deamon
  • Design and add the D-Bus interface, including the TPO value, and the setting (need further discussion)
  • Implement the D-Bus interface in the new TPO daemon.

Several questions to @vishwabmc:

1. Should the TPO feature has a setting to enable/disable (e.g. in /xyz/openbmc_project/settings)? E.g. when it is disabled, the daemon will report error on setting TPO timer, and getting the TPO timer will return 0;
2. If the above answer is yes, will the host be able to set the above setting? E.g. host could first enable the TPO and then set the TPO timer, both via PLDM.
3. When the TPO is enabled and the timer is set, and when the time is going to fire, what should BMC do if BMC is not ready to boot host? E.g. when TPO is going to boot host at 9:00 am, and BMC is rebooted during this period, should BMC boot host after it goes to ready state (e.g. at 9:02 am)?

[vishwabmc]

Several questions to @vishwabmc:

1. Should the TPO feature has a setting to enable/disable (e.g. in `/xyz/openbmc_project/settings`)?
   E.g. when it is disabled, the daemon will report error on setting TPO timer, and getting the TPO timer will return 0;

• Since this being a feature used by host, it may not be a user settable entity. Is there a way we can gate the external writes to this and allow internal writes only ?

2. If the above answer is yes, will the host be able to set the above setting?
   E.g. host could first enable the TPO and then set the TPO timer, both via PLDM.

• Irrespective of a setting in /xyz, host should be able to send a command to enable / disable. So this is anyway needed

3. When the TPO is enabled and the timer is set, and when the time is going to fire, what should BMC do if BMC is not ready to boot host?

   E.g. when TPO is going to boot host at 9:00 am, and BMC is rebooted during this period, should BMC boot host after it goes to ready state (e.g. at 9:02 am)?

• Correct. BMC needs to check if there was a TPO that had to be serviced and do so.

[vishwabmc]

The first thing is to have the PLDM back-end ready to carry the policy and the time since epoch We would also need to have a PLDM response indicating the SUCCESS or FAILURE ( with corresponding integer return codes )

[mine260309]

Since this being a feature used by host, it may not be a user settable entity. Is there a way we can gate the external writes to this and allow internal writes only ?

What do you mean by "internal writes"? Do you mean this setting is not settable by BMC's sysadmin , but only by Host firmware?

Irrespective of a setting in /xyz, host should be able to send a command to enable / disable. So this is anyway needed

The reason why I ask if there should be such a setting is because host is able to set the TPO without enable/disable setting. E.g.

• Host sets TPO to 0 indicates that TPO is disabled;
• Host set TOP to a valid date indicates that TPO is enabled and the timer is set

Do we really need a separated setting for the feature's enable/disable state? Especially you mentioned that the setting is only set internally (which I interpret as Host firmware could enable/disable it)

Correct. BMC needs to check if there was a TPO that had to be serviced and do so.

OK, sounds reasonable.

[vishwabmc]

Since this being a feature used by host, it may not be a user settable entity. Is there a way we can gate the external writes to this and allow internal writes only ?

What do you mean by "internal writes"? Do you mean this setting is not settable by BMC's sysadmin , but only by Host firmware?

Correct. This is an InBand mechanism only. So nothing needed in /xyz/openbmc

Irrespective of a setting in /xyz, host should be able to send a command to enable / disable. So this is anyway needed

The reason why I ask if there should be such a setting is because host is able to set the TPO without enable/disable setting. E.g.

* Host sets TPO to 0 indicates that TPO is disabled;

* Host set TOP to a valid date indicates that TPO is enabled and the timer is set

I agree with this. A value of [0] indicates no TPO.

Do we really need a separated setting for the feature's enable/disable state? Especially you mentioned that the setting is only set internally (which I interpret as Host firmware could enable/disable it)

Correct. BMC needs to check if there was a TPO that had to be serviced and do so.

OK, sounds reasonable.

[mine260309]

Good, so a summary:

• The TPO deamon
  • There is no need for a setting to enable/disable TPO;
    • Setting 0 to disable TPO;
    • Setting a valid date to enable TPO;
  • An interface will be added to phosphor-dbus-interface, and we will ask the community to see if it shall be put in /xyz/openbmc_project/ or /org/open_power/
  • A new TPO service will be created to implement the above interface;
• PLDM
  • Add PDR config for TPO
  • Implement SetNumericEffecter (or equivalent) command

[vishwabmc]

@mine260309 just want to add that "PowerOn must only be attempted if the system is in Normal Mode". Normal / Manual is a policy settable by user. But I believe, we could bake checking that into some systemd target and not needed part of any code

[mine260309]

@vishwabmc Could you elaborate on what the "Normal/Manual" mode is? Is it a property on D-Bus, or something else?

[vishwabmc]

@mine260309 This would be a setting in /xyz/openbmc, But we still need to see what is the best way to implement such a setting. For now, please ignore that setting. When we device such a setting, it would be a matter of checking that in some systemd target.. so no code changes would be needed.

[wangkair]

Where can we implement the interface? In phospher-state-manager or in a new built project? @vishwabmc @geissonator

[vishwabmc]

Where can we implement the interface? In phospher-state-manager or in a new built project? @vishwabmc @geissonator

@wangkair it will not be as part of phosphor-state-manager. it would be a different one.

To start with, could you help with PLDM changes ?

[wangkair]

Where can we implement the interface? In phospher-state-manager or in a new built project? @vishwabmc @geissonator

@wangkair it will not be as part of phosphor-state-manager. it would be a different one.

To start with, could you help with PLDM changes ?

Oh, I assigned the sub-issue to implement the interface, since I have no experience on interface coding and I want to learn it. :-)

[vishwabmc]

Oh, I assigned the sub-issue to implement the interface, since I have no experience on interface coding and I want to learn it. :-)

Sure.. We can implement this as a separate daemon inside phosphor-state-manager repo. Not sure if this is what you asked me before.

[mzipse]

Removing @wangkair as the owner as I don't believe she will be finishing this work. Let me know if anyone disagrees. Carol, if you are able, can you document what is completed and what is left to be done here?

[lxwinspur]

Hi, @mzipse Could we close this epic?

[mzipse]

We cannot close this yet. We confirmed that there is more work to do from a PLDM perspective. This function can be initiated from the Host OS. So the Host will need to communicate via PLDM to the BMC to set this timed power on function. This design topic has been identified but not clear how soon we will get to this. We will create a new PLDM story and link to this Epic once we understand the details of the PLDM design.

[mzipse]

Timed Power on work is now closed. Confirmed this with the PLDM team and Andrew.