[Skiboot] [PATCH v11 11/11] skiboot: Add documentation for IMC opal call
stewart at linux.vnet.ibm.com
Mon May 15 10:36:18 AEST 2017
Madhavan Srinivasan <maddy at linux.vnet.ibm.com> writes:
>> What's the behaviour over kexec? Calling _INIT multiple times is
>> harmless as long as no counters of that class are started?
> Yes that is true. Also we did test kexec path multiple times
> for all this three cases
> 1 )IMC kernel -> distro kernel (without IMC patchset)
> 2) distro kernel (without IMC Patchset) -> IMC kernel
> 3) IMC kernel -> IMC kernel.
Please document the intended behaviour of the OPAL API though. This will
help us in the future if/when we extend IMC to support other things.
>> This would imply that in a kdump scenario, the kdump kernel should *not*
>> init IMC counters, but in a normal kexec/boot scenario, it's safe to.
> Yes. In the kernel patchset, we do have a check for the kdump
> kernel before create IMC devices (in device probe function).
> So that we dont _INIT in the kdump scenerio
Okay, please document what the kernel is meant to do in the OPAL docs.
>>> +OPAL call interface for stoping In-Memory
>>> +Collection counters for a specified domain (NEST/CORE).
>>> +``uint32_t type``
>>> + This parameter specifies the imc counter domain.
>>> + The value can be either 'OPAL_IMC_COUNTERS_NEST'
>>> + or 'OPAL_IMC_COUNTERS_CORE'
>>> +OPAL_PARAMETER - In case of Unsupported ``type``
>>> +OPAL_HARDWARE - If xscom_write fails.
>>> +OPAL_SUCCESS - On successful execution of the operation for the given ``type``.
>> Will stop succeed if there has not been a corresponding START?
> Currently we dont check whether the counters are started,
> so STOP will succeed event there has not been a
> corresponding START
Is that intended design though? Must any future counters support that?
OPAL Architect, IBM.
More information about the Skiboot