| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aJGZ5_Sf4c1ByCeb@linux.ibm.com>
Date: Tue, 5 Aug 2025 11:13:03 +0530
From: Srikar Dronamraju <srikar@...ux.ibm.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
Tyrel Datwyler <tyreld@...ux.ibm.com>, linux-kernel@...r.kernel.org,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
Madhavan Srinivasan <maddy@...ux.ibm.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Naveen N Rao <naveen@...nel.org>
Subject: Re: [PATCH] pseries/lparcfg: Add resource group monitoring
* Shrikanth Hegde <sshegde@...ux.ibm.com> [2025-08-01 19:27:22]:
>
> On 7/16/25 16:15, Srikar Dronamraju wrote:
> > Systems can now be partitioned into resource groups. By default all
> > systems will be part of default resource group. Once a resource group is
> > created, and resources allocated to the resource group, those resources
> > will be removed from the default resource group. If a LPAR moved to a
> > resource group, then it can only use resources in the resource group.
> >
> > So maximum processors that can be allocated to a LPAR can be equal or
> > smaller than the resources in the resource group.
> >
> > lparcfg can now exposes the resource group id to which this LPAR belongs
> > to. It also exposes the number of processors in the current resource
> > group. The default resource group id happens to be 0. These would be
> > documented in the upcoming PAPR update.
>
> Could you please add a link to patch on power utils on how it is being consumed?
I am not sure I understood your query, it looks a bit ambiguous.
If your query is on how lparcfg data is being consumed.
All tools that are consuming lparcfg will continue to use the same way.
Since this is not changing the way lparcfg is being consumed, I think it is
redundant information that need not be carried in all the changes/commits to
lparcfg. Such an information would be required when lparcfg file was
created.
If your query is on how resource group data is being consumed by users.
Kernel is being transparent and reporting the information from the firmware.
This information is mostly for system administrators and they would already
known this info since they would be people who would have configured the
resource groups in the first place. Kernel doesnt provide a way to configure
resource group settings. This is more of a handy way to recollect the
information, rather than any action that needs to be taken.
>
> >
> > Example of an LPAR in a default resource group
> > root@...p11-lp3 $ grep resource_group /proc/powerpc/lparcfg
> > resource_group_number=0
> > resource_group_active_processors=50
> > root@...p11-lp3 $
> >
> > Example of an LPAR in a non-default resource group
> > root@...p11-lp5 $ grep resource_group /proc/powerpc/lparcfg
> > resource_group_number=1
> > resource_group_active_processors=30
> > root@...p11-lp5 $
> >
> > Cc: Madhavan Srinivasan <maddy@...ux.ibm.com>
> > Cc: Michael Ellerman <mpe@...erman.id.au>
> > Cc: Nicholas Piggin <npiggin@...il.com>
> > Cc: Christophe Leroy <christophe.leroy@...roup.eu>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: "Thomas Weißschuh" <thomas.weissschuh@...utronix.de>
> > Cc: Tyrel Datwyler <tyreld@...ux.ibm.com>
> > Cc: linuxppc-dev@...ts.ozlabs.org
> > Cc: linux-kernel@...r.kernel.org
> > Signed-off-by: Srikar Dronamraju <srikar@...ux.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/lparcfg.c | 17 ++++++++++++++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> > index cc22924f159f..6554537984fb 100644
> > --- a/arch/powerpc/platforms/pseries/lparcfg.c
> > +++ b/arch/powerpc/platforms/pseries/lparcfg.c
>
> Does MODULE_VERS need to increased?
All tools that are consuming lparcfg will continue to use the same way.
If there was some conditional changes that need to be done by the tools,
then we should have updated the same.
Hence there is not need to update MODULE_VERS.
>
> > @@ -78,6 +78,8 @@ struct hvcall_ppp_data {
> > u8 capped;
> > u8 weight;
> > u8 unallocated_weight;
> > + u8 resource_group_index;
> > + u16 active_procs_in_resource_group;
> > u16 active_procs_in_pool;
> > u16 active_system_procs;
> > u16 phys_platform_procs;
> > @@ -86,7 +88,7 @@ struct hvcall_ppp_data {
> > };
> > /*
> > - * H_GET_PPP hcall returns info in 4 parms.
> > + * H_GET_PPP hcall returns info in 5 parms.
> > * entitled_capacity,unallocated_capacity,
> > * aggregation, resource_capability).
> > *
> > @@ -94,11 +96,11 @@ struct hvcall_ppp_data {
> > * R5 = Unallocated Processor Capacity Percentage.
> > * R6 (AABBCCDDEEFFGGHH).
> > * XXXX - reserved (0)
> > - * XXXX - reserved (0)
> > + * XXXX - Active Cores in Resource Group
> > * XXXX - Group Number
> > * XXXX - Pool Number.
> > * R7 (IIJJKKLLMMNNOOPP).
> > - * XX - reserved. (0)
> > + * XX - Resource group Number
> > * XX - bit 0-6 reserved (0). bit 7 is Capped indicator.
> > * XX - variable processor Capacity Weight
> > * XX - Unallocated Variable Processor Capacity Weight.
> > @@ -120,9 +122,11 @@ static unsigned int h_get_ppp(struct hvcall_ppp_data *ppp_data)
> > ppp_data->entitlement = retbuf[0];
> > ppp_data->unallocated_entitlement = retbuf[1];
> > + ppp_data->active_procs_in_resource_group = (retbuf[2] >> 4 * 8) & 0xffff;
> > ppp_data->group_num = (retbuf[2] >> 2 * 8) & 0xffff;
> > ppp_data->pool_num = retbuf[2] & 0xffff;
> > + ppp_data->resource_group_index = (retbuf[3] >> 7 * 8) & 0xff;
> > ppp_data->capped = (retbuf[3] >> 6 * 8) & 0x01;
> > ppp_data->weight = (retbuf[3] >> 5 * 8) & 0xff;
> > ppp_data->unallocated_weight = (retbuf[3] >> 4 * 8) & 0xff;
> > @@ -236,6 +240,13 @@ static void parse_ppp_data(struct seq_file *m)
> > seq_printf(m, "unallocated_capacity=%lld\n",
> > ppp_data.unallocated_entitlement);
> > + if (ppp_data.active_procs_in_resource_group) {
>
> ppp_data.active_procs_in_resource_group can ever be zero?
>
> If the entry is absent in lparcfg, then lparstat will print it as 0 (which happens to be
> default RG, while default RG may have processors)
If active_procs_in_resource_group is 0, then we are not printing the
resource group information. If active_procs_in_resource_group is non-zero
and resource_group_index is wrong, we need to report a bug to the firmware
to update it. Kernel is very transparent with respect to this information.
It can neither verify the information received nor should we even be doing
this.
>
> > + seq_printf(m, "resource_group_number=%d\n",
> > + ppp_data.resource_group_index);
> > + seq_printf(m, "resource_group_active_processors=%d\n",
> > + ppp_data.active_procs_in_resource_group);
> > + }
> > +
> > /* The last bits of information returned from h_get_ppp are only
> > * valid if the ibm,partition-performance-parameters-level
> > * property is >= 1.
>
--
Thanks and Regards
Srikar Dronamraju
Powered by blists - more mailing lists