Re: [PATCH v3] powerpc/pseries: read the lpar name from the firmware

Laurent Dufour [off-list ref] writes:

On 08/12/2021, 16:21:29, Nathan Lynch wrote:

quoted

Laurent Dufour [off-list ref] writes:

quoted

On 07/12/2021, 18:07:50, Nathan Lynch wrote:

quoted

Laurent Dufour [off-list ref] writes:

quoted

On 07/12/2021, 15:32:39, Nathan Lynch wrote:

quoted

Is there a reasonable fallback for VMs where this parameter doesn't
exist? PowerVM partitions should always have it, but what do we want the
behavior to be on other hypervisors?

In that case, there is no value displayed in the /proc/powerpc/lparcfg and
the lparstat -i command will fall back to the device tree value. I can't
see any valid reason to report the value defined in the device tree
here.

Here's a valid reason :-)

lparstat isn't the only possible consumer of the interface, and the
'ibm,partition-name' property and the dynamic system parameter clearly
serve a common purpose. 'ibm,partition-name' is provided by qemu.

If the hypervisor is not providing this value, this is not the goal of this
interface to fetch it from the device tree.

Any consumer should be able to fall back on the device tree value, and
there is no added value to do such a trick in the kernel when it can be
done in the user space.

There is value in imposing a level of abstraction so that the semantics
are:

* Report the name assigned to the guest by the hosting environment, if
  available

as opposed to

* Return the string returned by a RTAS call to ibm,get-system-parameter
  with token 55, if implemented

The benefit is that consumers of lparcfg do not have to be coded with
the knowledge that "if a partition_name= line is absent, the
ibm,get-system-parameter RTAS call must have failed, so now I should
read /sys/firmware/devicetree/base/ibm,partition_name." That's the sort
of esoterica that is appropriate for the kernel to encapsulate.

And I'd say the effort involved (falling back to a root node property
lookup) is proportional to the benefit.

I don't agree.
From the kernel point of view, I can't see any benefit, this is adding more
complexity to do in the kernel what can be done easily in user space.

Applying this logic, I don't see how adding this to lparcfg would be
justified at all, because user space can already get at the parameter
using the privileged rtas syscall. Publish it to unprivileged programs
over D-Bus or something. That would minimize complexity for the kernel.