Nvidia proposal to extend 196 Boot Progress

[RezaBacchus]

This is an excellent start. Please consider the following:

1. Make the Boot Stages generic to give flexibility to the vendors.
2. Are 2 generic Boot Stage enough? Is a 3rd generic Boot Stage useful?
3. Add a command-response for the xPU to return a 64-bit monotonically increasing boot sequence (MIBS). This is a debug aid. For example, if the xPU continuously returns Boot Stage 1, monitoring MIBS differentiates if it is stuck or being rebooted. Let us debate if MIBS should be reported with each boot status or as a separate command-response.
4. Are the Crash Dump statuses an appropriate fit for the Boot Progress set of responses? Should it be "Boot Progress and OS Status"?
5. Add an OS halted state.

[glimchb]

do we want something more concrete about secure boot? for example if boot image verification fails, there is concrete action we can take and it is much more informative then we just not moving to the next stage without knowing why... wdyt?

[juliakreger]

We were able to discuss this during yesterday's meeting, the TL;DR I put in slack (because we couldn't record the meeting) is as follows:

So we discussed today, and the consensus we sort of reached was that we need to mutually go wrap our heads around DSP2054 since that is the NIC modeling, and then determine if a new document and standard is needed.

One overall concern which we shared today was that values having multiple cross vendor meanings, when the existing standard has states defined up to 26 for value 196, so the underlying concern is modeling (leading to DSP2054) and then the need to have it be standardized and not try to override the dmtf status meaning. Lee indicated he would take look at making a 3 way table to try and then extract the needful values which don't already exist.

The driver for modeling was the reality of needing to possibly enable accounting for if the AMC is actually a VM on the core.

[RezaBacchus]

Another suggestion is to create a Redfish Profile for xPUs as described in DSP0272. xPUs are an emerging technology with ample capability. ENUMs and decoder rings were popular when resources were highly constrained. Let's move away from ENUMs to more readable communications.

[juliakreger]

I think we're sort of on divergent but complimentary trains of thought as the thread of discussion was on PLDM related data modeling where we're in the world of enum values all with the purpose to aid in boot coordination.

I think the discussion has always been to create a Redfish profile as well for end user interaction with the device, unless your advocating we ignore PLDM entirely and require Redfish to be used for inter-device boot coordination?

Or are you suggesting we model the interaction for end users to drive the boot coordination?

With Redfish, we still have ENUMs there the form of a fixed list of possible value there for boot progress, although there is also the free form Oem Boot Progress field, but I'm not sure we should build any consensus around mandated use of an Oem field. At least, that is just my opinion.