The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Cc: Nathan Lynch <redacted>
Signed-off-by: Laurent Dufour <redacted>
---
v4:
address Nathan's new comments limiting size of the buffer.
v3:
address Michael's comments.
v2:
address Nathan's comments.
change title to partition_name aligning with existing partition_id
---
arch/powerpc/platforms/pseries/lparcfg.c | 54 ++++++++++++++++++++++++
1 file changed, 54 insertions(+)
Happy New Year, Michael!
Do you consider taking that patch soon?
Thanks,
Laurent.
On 07/12/2021, 18:11:09, Laurent Dufour wrote:
quoted hunk
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Cc: Nathan Lynch <redacted>
Signed-off-by: Laurent Dufour <redacted>
---
v4:
address Nathan's new comments limiting size of the buffer.
v3:
address Michael's comments.
v2:
address Nathan's comments.
change title to partition_name aligning with existing partition_id
---
arch/powerpc/platforms/pseries/lparcfg.c | 54 ++++++++++++++++++++++++
1 file changed, 54 insertions(+)
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Do you consider taking that patch soon?
This version prints an error on non-PowerVM guests the first time
lparcfg is read.
And I still contend that having this function fall back to reporting the
partition name in the DT would provide a beneficial consistency in the
user-facing API, allowing programs to avoid hypervisor-specific branches
in their code. I don't understand the resistance I've encountered here.
The fallback I'm suggesting (a root node property lookup) is certainly
not more complex than the RTAS call sequence you've already implemented.
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Do you consider taking that patch soon?
This version prints an error on non-PowerVM guests the first time
lparcfg is read.
I assume because QEMU doesn't implement the LPAR_NAME token for get_sysparm.
And I still contend that having this function fall back to reporting the
partition name in the DT would provide a beneficial consistency in the
user-facing API, allowing programs to avoid hypervisor-specific branches
in their code.
Agreed, if the get_sysparm fails just report the lpar-name from the device tree.
I don't understand the resistance I've encountered here.
The fallback I'm suggesting (a root node property lookup) is certainly
not more complex than the RTAS call sequence you've already implemented.
Is there benefit of adding a partition_name field/value pair to lparcfg? The
lparstat utility can just as easily make the get_sysparm call via librtas.
Further, rtas_filters allows this particular RTAS call from userspace.
-Tyrel
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Do you consider taking that patch soon?
This version prints an error on non-PowerVM guests the first time
lparcfg is read.
I assume because QEMU doesn't implement the LPAR_NAME token for
get_sysparm.
Correct.
quoted
And I still contend that having this function fall back to reporting the
partition name in the DT would provide a beneficial consistency in the
user-facing API, allowing programs to avoid hypervisor-specific branches
in their code.
Agreed, if the get_sysparm fails just report the lpar-name from the device tree.
quoted
I don't understand the resistance I've encountered here.
The fallback I'm suggesting (a root node property lookup) is certainly
not more complex than the RTAS call sequence you've already implemented.
Is there benefit of adding a partition_name field/value pair to lparcfg? The
lparstat utility can just as easily make the get_sysparm call via librtas.
Further, rtas_filters allows this particular RTAS call from userspace.
The RTAS syscall is root-only, but we want the partition name (whether
supplied by RTAS or the device tree) to be available to unprivileged
programs.
Is there benefit of adding a partition_name field/value pair to lparcfg? The
lparstat utility can just as easily make the get_sysparm call via librtas.
Further, rtas_filters allows this particular RTAS call from userspace.
The RTAS syscall is root-only, but we want the partition name (whether
supplied by RTAS or the device tree) to be available to unprivileged
programs.
Ah, right. I recall this discussion now from previous iterations.
-Tyrel
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Do you consider taking that patch soon?
This version prints an error on non-PowerVM guests the first time
lparcfg is read.
I assume because QEMU doesn't implement the LPAR_NAME token for get_sysparm.
quoted
And I still contend that having this function fall back to reporting the
partition name in the DT would provide a beneficial consistency in the
user-facing API, allowing programs to avoid hypervisor-specific branches
in their code.
Agreed, if the get_sysparm fails just report the lpar-name from the device tree.
My aim is to not do in the kernel what can be easily done in user space but
avoiding user space program hypervisor-specific branches is a good point.
Note that if the RTAS call has been available to unprivileged user, all
that stuff would have been made in user space, so hypervisor-specific...
Anyway, I'll work on a new version fetching the DT value in the case the
RTAS call is failing.
Thanks,
Laurent.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2022-01-06 23:09:38
Laurent Dufour [off-list ref] writes:
Happy New Year, Michael!
Do you consider taking that patch soon?
I did but I was hoping you and Nathan could come to an agreement.
Looks like you did while I was sleeping, perfect :)
I'll pick up v5.
cheers
On 07/12/2021, 18:11:09, Laurent Dufour wrote:
quoted
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Cc: Nathan Lynch <redacted>
Signed-off-by: Laurent Dufour <redacted>
---
v4:
address Nathan's new comments limiting size of the buffer.
v3:
address Michael's comments.
v2:
address Nathan's comments.
change title to partition_name aligning with existing partition_id
---
arch/powerpc/platforms/pseries/lparcfg.c | 54 ++++++++++++++++++++++++
1 file changed, 54 insertions(+)