On 1/5/22 3:19 PM, Nathan Lynch wrote: > Laurent Dufour <lduf...@linux.ibm.com> writes: >> On 07/12/2021, 18:11:09, Laurent Dufour wrote: >>> 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
