[Skiboot] [PATCH v2] core/init: Add ibm, processor-storage-keys property to /cpus DT node.

Michael Ellerman mpe at ellerman.id.au
Mon Feb 26 12:09:15 AEDT 2018


Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> writes:
> Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> writes:
>> Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> writes:
>>
>>> LoPAPR says:
>>>
>>>     “ibm,processor-storage-keys”
>>>
>>>     property name indicating the number of virtual storage keys supported
>>>     by the processor described by this node.
>>>
>>>     prop-encoded-array: Consists of two cells encoded as with encode-int.
>>>     The first cell represents the number of virtual storage keys supported
>>>     for data accesses while the second cell represents the number of
>>>     virtual storage keys supported for instruction accesses. The cell value
>>>     of zero indicates that no storage keys are supported for the access
>>>     type.
>>>
>>> pHyp provides the property above but there's a bug in P8 firmware where the
>>> second cell is zero even though POWER8 supports instruction access keys.
>>> This bug will be fixed for P9.
>>>
>>> While this is a PAPR property, it's useful to have it in powernv as well
>>> so that Linux has a uniform way of checking for the feature regardless of
>>> the platform it's running on.
>>>
>>> On PAPR there is one property for each CPU node, but since it's highly
>>> unlikely that different CPUs will support a different number of keys, we
>>> put the property in the /cpus node instead.
>>>
>>> Tested on QEMU POWER8 powernv model and Mambo P9.
>>>
>>> Signed-off-by: Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com>
>>> ---
>>>  core/init.c | 18 ++++++++++++++++++
>>>  1 file changed, 18 insertions(+)
>>>
>>> Changes in v2:
>>> - Put property in /cpus instead of in each CPU node.
>>
>> Ping?
>
> Ping? This patch still applies cleanly and works.
>
> The Linux kernel patches using this property are upstream now (as of
> v4.16-rc1) and we are still interested in having it on OpenPower
> machines.
>
> The only open issue is where to put the property. Currently, the Linux
> code only looks for it in nodes with device_type = "cpu". This patch
> puts it in /cpus to avoid repeating the property in each CPU node, but
> Michael Ellerman suggested putting it in the ibm,opal node instead.

Hmm did I, probably :)

It's annoying the way these properties get multiplied for each CPU, but
for now we should probably just stick with tradition and put it in each
CPU node.

Sorry to change my mind on that. Are you able to respin it with that
change?

cheers


More information about the Skiboot mailing list