|
Post by Michael Shen on Feb 8, 2023 5:56:19 GMT
Hi all, I would like to ask why is the ProcessorId.Step type a string? Is there any constraint on it? Currently OpenBMC uses `uint16_t` to present Step. I am proposing to change that type to `string` due to an issue (unrelated to this discussion). Also this proposal can make `Step` aligned with Redfish. Thus, we would like to consult the redfish forum first to know why Redfish uses `string` on `Step`. Is there any constraint on it? If not, wouldn't it be easily ambiguous? Thanks, Michael
|
|
|
Post by mraineri on Feb 8, 2023 13:35:14 GMT
It's a string to allow for flexibility with how various CPU architectures might want to represent their data. Specific with x86, it's common when discussing processor ID registers (like the step) with others as hex values, but JSON does not allow hex values to be encoded natively; the pattern we use elsewhere in Redfish is when we want data to be shown in hex, we use a string representation of the hex value. This is a sample from one of our mockups showing this:
"ProcessorId": { "VendorId": "GenuineIntel", "IdentificationRegisters": "0x34AC34DC8901274A", "EffectiveFamily": "0x42", "EffectiveModel": "0x61", "Step": "0x1", "MicrocodeInfo": "0x429943" },
If you refer to the Redfish Data Model Specification (https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2022.3.pdf) there is supplemental documentation provided that shows specific encodings for different CPU architectures (section 6.93.5.19 specifically for "Step"). At this time we only have details filled out for x86. I also see that we don't go so far as to state the value obtained from various CPU registers is to be encoded as a hex string; this is something I think we need to add.
|
|
|
Post by Michael Shen on Feb 9, 2023 6:11:53 GMT
Thanks for the detailed explanation! I listed 2 conclusions below. Just want to double check I understand correctly.
1. For `x86` CPUs, we expected its `Step` follows this algorithm. ``` (eax, ebx, ecx, edx) = cpuid(eax=0x1); Step = (eax & 0x000F); ``` Which guarantees the value can be encoded to a hex string.
2. For non-x86 CPUs, we can’t ensure its CPU register value can be encoded as a hex string. So it could be various.
|
|
|
Post by mraineri on Feb 9, 2023 13:19:39 GMT
For 1), there is is a gap in the documentation with what to do with the value of "Step" at the end of that pseudocode. It doesn't explicitly state that it's converted to a hex string when building the JSON response.
For 2), that's right, we can't do that at the moment and so it's fairly open-ended. We're reliant on SMEs of other CPU architectures to give us that input, and once we get it, we can add more documentation to cover other things like ARM processors.
|
|
|
Post by Michael Shen on Feb 9, 2023 23:58:48 GMT
Got it. Thanks again!
|
|