Tyrel Datwyler <tyr...@linux.ibm.com> writes: > 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.
Correct. >> 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. 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.
