* Re: [PATCH v5 1/6] powerpc/pseries: rename min_common_depth to primary_domain_index
From: David Gibson @ 2021-07-22 1:59 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <20210628151117.545935-2-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5234 bytes --]
On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch.
The new name does not match how you describe "primary domain index" in
the documentation from patch 6/6. There it comes from the values in
associativity-reference-points, but here it simply comes from the
lengths of all the associativity properties.
>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 38 +++++++++++++++++++-------------------
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index f2bf98bdcea2..8365b298ec48 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -51,7 +51,7 @@ EXPORT_SYMBOL(numa_cpu_lookup_table);
> EXPORT_SYMBOL(node_to_cpumask_map);
> EXPORT_SYMBOL(node_data);
>
> -static int min_common_depth;
> +static int primary_domain_index;
> static int n_mem_addr_cells, n_mem_size_cells;
> static int form1_affinity;
>
> @@ -232,8 +232,8 @@ static int associativity_to_nid(const __be32 *associativity)
> if (!numa_enabled)
> goto out;
>
> - if (of_read_number(associativity, 1) >= min_common_depth)
> - nid = of_read_number(&associativity[min_common_depth], 1);
> + if (of_read_number(associativity, 1) >= primary_domain_index)
> + nid = of_read_number(&associativity[primary_domain_index], 1);
>
> /* POWER4 LPAR uses 0xffff as invalid node */
> if (nid == 0xffff || nid >= nr_node_ids)
> @@ -284,9 +284,9 @@ int of_node_to_nid(struct device_node *device)
> }
> EXPORT_SYMBOL(of_node_to_nid);
>
> -static int __init find_min_common_depth(void)
> +static int __init find_primary_domain_index(void)
> {
> - int depth;
> + int index;
> struct device_node *root;
>
> if (firmware_has_feature(FW_FEATURE_OPAL))
> @@ -326,7 +326,7 @@ static int __init find_min_common_depth(void)
> }
>
> if (form1_affinity) {
> - depth = of_read_number(distance_ref_points, 1);
> + index = of_read_number(distance_ref_points, 1);
> } else {
> if (distance_ref_points_depth < 2) {
> printk(KERN_WARNING "NUMA: "
> @@ -334,7 +334,7 @@ static int __init find_min_common_depth(void)
> goto err;
> }
>
> - depth = of_read_number(&distance_ref_points[1], 1);
> + index = of_read_number(&distance_ref_points[1], 1);
> }
>
> /*
> @@ -348,7 +348,7 @@ static int __init find_min_common_depth(void)
> }
>
> of_node_put(root);
> - return depth;
> + return index;
>
> err:
> of_node_put(root);
> @@ -437,16 +437,16 @@ int of_drconf_to_nid_single(struct drmem_lmb *lmb)
> int nid = default_nid;
> int rc, index;
>
> - if ((min_common_depth < 0) || !numa_enabled)
> + if ((primary_domain_index < 0) || !numa_enabled)
> return default_nid;
>
> rc = of_get_assoc_arrays(&aa);
> if (rc)
> return default_nid;
>
> - if (min_common_depth <= aa.array_sz &&
> + if (primary_domain_index <= aa.array_sz &&
> !(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
> - index = lmb->aa_index * aa.array_sz + min_common_depth - 1;
> + index = lmb->aa_index * aa.array_sz + primary_domain_index - 1;
> nid = of_read_number(&aa.arrays[index], 1);
>
> if (nid == 0xffff || nid >= nr_node_ids)
> @@ -708,18 +708,18 @@ static int __init parse_numa_properties(void)
> return -1;
> }
>
> - min_common_depth = find_min_common_depth();
> + primary_domain_index = find_primary_domain_index();
>
> - if (min_common_depth < 0) {
> + if (primary_domain_index < 0) {
> /*
> - * if we fail to parse min_common_depth from device tree
> + * if we fail to parse primary_domain_index from device tree
> * mark the numa disabled, boot with numa disabled.
> */
> numa_enabled = false;
> - return min_common_depth;
> + return primary_domain_index;
> }
>
> - dbg("NUMA associativity depth for CPU/Memory: %d\n", min_common_depth);
> + dbg("NUMA associativity depth for CPU/Memory: %d\n", primary_domain_index);
>
> /*
> * Even though we connect cpus to numa domains later in SMP
> @@ -919,14 +919,14 @@ static void __init find_possible_nodes(void)
> goto out;
> }
>
> - max_nodes = of_read_number(&domains[min_common_depth], 1);
> + max_nodes = of_read_number(&domains[primary_domain_index], 1);
> for (i = 0; i < max_nodes; i++) {
> if (!node_possible(i))
> node_set(i, node_possible_map);
> }
>
> prop_length /= sizeof(int);
> - if (prop_length > min_common_depth + 2)
> + if (prop_length > primary_domain_index + 2)
> coregroup_enabled = 1;
>
> out:
> @@ -1259,7 +1259,7 @@ int cpu_to_coregroup_id(int cpu)
> goto out;
>
> index = of_read_number(associativity, 1);
> - if (index > min_common_depth + 1)
> + if (index > primary_domain_index + 1)
> return of_read_number(&associativity[index - 1], 1);
>
> out:
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/6] powerpc/pseries: rename distance_ref_points_depth to max_associativity_domain_index
From: David Gibson @ 2021-07-22 0:59 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <20210628151117.545935-3-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]
On Mon, Jun 28, 2021 at 08:41:13PM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/mm/numa.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 8365b298ec48..132813dd1a6c 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -56,7 +56,7 @@ static int n_mem_addr_cells, n_mem_size_cells;
> static int form1_affinity;
>
> #define MAX_DISTANCE_REF_POINTS 4
> -static int distance_ref_points_depth;
> +static int max_associativity_domain_index;
> static const __be32 *distance_ref_points;
> static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
>
> @@ -169,7 +169,7 @@ int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>
> int i, index;
>
> - for (i = 0; i < distance_ref_points_depth; i++) {
> + for (i = 0; i < max_associativity_domain_index; i++) {
> index = be32_to_cpu(distance_ref_points[i]);
> if (cpu1_assoc[index] == cpu2_assoc[index])
> break;
> @@ -193,7 +193,7 @@ int __node_distance(int a, int b)
> if (!form1_affinity)
> return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);
>
> - for (i = 0; i < distance_ref_points_depth; i++) {
> + for (i = 0; i < max_associativity_domain_index; i++) {
> if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
> break;
>
> @@ -213,7 +213,7 @@ static void initialize_distance_lookup_table(int nid,
> if (!form1_affinity)
> return;
>
> - for (i = 0; i < distance_ref_points_depth; i++) {
> + for (i = 0; i < max_associativity_domain_index; i++) {
> const __be32 *entry;
>
> entry = &associativity[be32_to_cpu(distance_ref_points[i]) - 1];
> @@ -240,7 +240,7 @@ static int associativity_to_nid(const __be32 *associativity)
> nid = NUMA_NO_NODE;
>
> if (nid > 0 &&
> - of_read_number(associativity, 1) >= distance_ref_points_depth) {
> + of_read_number(associativity, 1) >= max_associativity_domain_index) {
> /*
> * Skip the length field and send start of associativity array
> */
> @@ -310,14 +310,14 @@ static int __init find_primary_domain_index(void)
> */
> distance_ref_points = of_get_property(root,
> "ibm,associativity-reference-points",
> - &distance_ref_points_depth);
> + &max_associativity_domain_index);
>
> if (!distance_ref_points) {
> dbg("NUMA: ibm,associativity-reference-points not found.\n");
> goto err;
> }
>
> - distance_ref_points_depth /= sizeof(int);
> + max_associativity_domain_index /= sizeof(int);
>
> if (firmware_has_feature(FW_FEATURE_OPAL) ||
> firmware_has_feature(FW_FEATURE_TYPE1_AFFINITY)) {
> @@ -328,7 +328,7 @@ static int __init find_primary_domain_index(void)
> if (form1_affinity) {
> index = of_read_number(distance_ref_points, 1);
> } else {
> - if (distance_ref_points_depth < 2) {
> + if (max_associativity_domain_index < 2) {
> printk(KERN_WARNING "NUMA: "
> "short ibm,associativity-reference-points\n");
> goto err;
> @@ -341,10 +341,10 @@ static int __init find_primary_domain_index(void)
> * Warn and cap if the hardware supports more than
> * MAX_DISTANCE_REF_POINTS domains.
> */
> - if (distance_ref_points_depth > MAX_DISTANCE_REF_POINTS) {
> + if (max_associativity_domain_index > MAX_DISTANCE_REF_POINTS) {
> printk(KERN_WARNING "NUMA: distance array capped at "
> "%d entries\n", MAX_DISTANCE_REF_POINTS);
> - distance_ref_points_depth = MAX_DISTANCE_REF_POINTS;
> + max_associativity_domain_index = MAX_DISTANCE_REF_POINTS;
> }
>
> of_node_put(root);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/6] powerpc/pseries: rename min_common_depth to primary_domain_index
From: David Gibson @ 2021-07-22 2:36 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <YPjQ85wtr165BOMa@yekko>
[-- Attachment #1: Type: text/plain, Size: 4309 bytes --]
On Thu, Jul 22, 2021 at 11:59:15AM +1000, David Gibson wrote:
> On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
> > No functional change in this patch.
>
> The new name does not match how you describe "primary domain index" in
> the documentation from patch 6/6. There it comes from the values in
> associativity-reference-points, but here it simply comes from the
> lengths of all the associativity properties.
No, sorry, I misread this code... misled by the old name, so it's a
good thing you're changing it.
But.. I'm still not sure the new name is accurate, either...
[snip]
> > if (form1_affinity) {
> > - depth = of_read_number(distance_ref_points, 1);
> > + index = of_read_number(distance_ref_points, 1);
AFACIT distance_ref_points hasn't been altered from the
of_get_property() at this point, so isn't this setting depth / index
to the number of entries in ref-points, rather than the value of the
first entry (which is what primary domain index is supposed to be).
> > } else {
> > if (distance_ref_points_depth < 2) {
> > printk(KERN_WARNING "NUMA: "
> > @@ -334,7 +334,7 @@ static int __init find_min_common_depth(void)
> > goto err;
> > }
> >
> > - depth = of_read_number(&distance_ref_points[1], 1);
> > + index = of_read_number(&distance_ref_points[1], 1);
> > }
> >
> > /*
> > @@ -348,7 +348,7 @@ static int __init find_min_common_depth(void)
> > }
> >
> > of_node_put(root);
> > - return depth;
> > + return index;
> >
> > err:
> > of_node_put(root);
> > @@ -437,16 +437,16 @@ int of_drconf_to_nid_single(struct drmem_lmb *lmb)
> > int nid = default_nid;
> > int rc, index;
> >
> > - if ((min_common_depth < 0) || !numa_enabled)
> > + if ((primary_domain_index < 0) || !numa_enabled)
> > return default_nid;
> >
> > rc = of_get_assoc_arrays(&aa);
> > if (rc)
> > return default_nid;
> >
> > - if (min_common_depth <= aa.array_sz &&
> > + if (primary_domain_index <= aa.array_sz &&
> > !(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
> > - index = lmb->aa_index * aa.array_sz + min_common_depth - 1;
> > + index = lmb->aa_index * aa.array_sz + primary_domain_index - 1;
> > nid = of_read_number(&aa.arrays[index], 1);
> >
> > if (nid == 0xffff || nid >= nr_node_ids)
> > @@ -708,18 +708,18 @@ static int __init parse_numa_properties(void)
> > return -1;
> > }
> >
> > - min_common_depth = find_min_common_depth();
> > + primary_domain_index = find_primary_domain_index();
> >
> > - if (min_common_depth < 0) {
> > + if (primary_domain_index < 0) {
> > /*
> > - * if we fail to parse min_common_depth from device tree
> > + * if we fail to parse primary_domain_index from device tree
> > * mark the numa disabled, boot with numa disabled.
> > */
> > numa_enabled = false;
> > - return min_common_depth;
> > + return primary_domain_index;
> > }
> >
> > - dbg("NUMA associativity depth for CPU/Memory: %d\n", min_common_depth);
> > + dbg("NUMA associativity depth for CPU/Memory: %d\n", primary_domain_index);
> >
> > /*
> > * Even though we connect cpus to numa domains later in SMP
> > @@ -919,14 +919,14 @@ static void __init find_possible_nodes(void)
> > goto out;
> > }
> >
> > - max_nodes = of_read_number(&domains[min_common_depth], 1);
> > + max_nodes = of_read_number(&domains[primary_domain_index], 1);
> > for (i = 0; i < max_nodes; i++) {
> > if (!node_possible(i))
> > node_set(i, node_possible_map);
> > }
> >
> > prop_length /= sizeof(int);
> > - if (prop_length > min_common_depth + 2)
> > + if (prop_length > primary_domain_index + 2)
> > coregroup_enabled = 1;
> >
> > out:
> > @@ -1259,7 +1259,7 @@ int cpu_to_coregroup_id(int cpu)
> > goto out;
> >
> > index = of_read_number(associativity, 1);
> > - if (index > min_common_depth + 1)
> > + if (index > primary_domain_index + 1)
> > return of_read_number(&associativity[index - 1], 1);
> >
> > out:
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS bbff45e5b6020c1259f90034926aef03dce1803d
From: kernel test robot @ 2021-07-22 5:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: bbff45e5b6020c1259f90034926aef03dce1803d Automatic merge of 'fixes' into merge (2021-07-21 17:33)
elapsed time: 1198m
configs tested: 155
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
xtensa audio_kc705_defconfig
powerpc tqm8540_defconfig
powerpc mpc834x_mds_defconfig
openrisc or1ksim_defconfig
sh lboxre2_defconfig
powerpc ebony_defconfig
powerpc bamboo_defconfig
arm integrator_defconfig
arm multi_v7_defconfig
powerpc storcenter_defconfig
powerpc tqm8548_defconfig
arm multi_v5_defconfig
mips ath25_defconfig
sh se7721_defconfig
powerpc pasemi_defconfig
m68k mvme16x_defconfig
sh r7785rp_defconfig
sparc64 defconfig
arc nsimosci_hs_defconfig
m68k allyesconfig
powerpc tqm8xx_defconfig
powerpc ge_imp3a_defconfig
csky alldefconfig
h8300 defconfig
sh sh7785lcr_32bit_defconfig
mips jazz_defconfig
sh sdk7786_defconfig
arm stm32_defconfig
arm viper_defconfig
mips vocore2_defconfig
sh rsk7201_defconfig
arm bcm2835_defconfig
powerpc mgcoge_defconfig
riscv alldefconfig
microblaze defconfig
mips tb0287_defconfig
sh titan_defconfig
arc nsim_700_defconfig
riscv rv32_defconfig
powerpc mpc866_ads_defconfig
mips loongson2k_defconfig
sh ecovec24-romimage_defconfig
arm ep93xx_defconfig
powerpc wii_defconfig
sh se7343_defconfig
m68k m5407c3_defconfig
arm realview_defconfig
arm dove_defconfig
arm colibri_pxa270_defconfig
openrisc simple_smp_defconfig
mips ip28_defconfig
arm64 alldefconfig
mips cu1000-neo_defconfig
riscv nommu_virt_defconfig
mips decstation_r4k_defconfig
xtensa nommu_kc705_defconfig
sh polaris_defconfig
mips fuloong2e_defconfig
powerpc holly_defconfig
arm mps2_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
x86_64 allnoconfig
m68k allmodconfig
m68k defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a003-20210720
x86_64 randconfig-a006-20210720
x86_64 randconfig-a001-20210720
x86_64 randconfig-a005-20210720
x86_64 randconfig-a004-20210720
x86_64 randconfig-a002-20210720
i386 randconfig-a005-20210720
i386 randconfig-a003-20210720
i386 randconfig-a004-20210720
i386 randconfig-a002-20210720
i386 randconfig-a001-20210720
i386 randconfig-a006-20210720
i386 randconfig-a005-20210722
i386 randconfig-a003-20210722
i386 randconfig-a004-20210722
i386 randconfig-a002-20210722
i386 randconfig-a001-20210722
i386 randconfig-a006-20210722
i386 randconfig-a005-20210719
i386 randconfig-a004-20210719
i386 randconfig-a006-20210719
i386 randconfig-a001-20210719
i386 randconfig-a003-20210719
i386 randconfig-a002-20210719
i386 randconfig-a016-20210720
i386 randconfig-a013-20210720
i386 randconfig-a012-20210720
i386 randconfig-a014-20210720
i386 randconfig-a011-20210720
i386 randconfig-a015-20210720
i386 randconfig-a016-20210721
i386 randconfig-a013-20210721
i386 randconfig-a012-20210721
i386 randconfig-a014-20210721
i386 randconfig-a011-20210721
i386 randconfig-a015-20210721
riscv nommu_k210_defconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210720
x86_64 randconfig-a011-20210722
x86_64 randconfig-a003-20210721
x86_64 randconfig-a006-20210721
x86_64 randconfig-a001-20210721
x86_64 randconfig-a005-20210721
x86_64 randconfig-a004-20210721
x86_64 randconfig-a002-20210721
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v5 1/6] powerpc/pseries: rename min_common_depth to primary_domain_index
From: Aneesh Kumar K.V @ 2021-07-22 5:17 UTC (permalink / raw)
To: David Gibson; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <YPjZvgRr2WSdcX/W@yekko>
On 7/22/21 8:06 AM, David Gibson wrote:
> On Thu, Jul 22, 2021 at 11:59:15AM +1000, David Gibson wrote:
>> On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
>>> No functional change in this patch.
>>
>> The new name does not match how you describe "primary domain index" in
>> the documentation from patch 6/6. There it comes from the values in
>> associativity-reference-points, but here it simply comes from the
>> lengths of all the associativity properties.
>
> No, sorry, I misread this code... misled by the old name, so it's a
> good thing you're changing it.
>
> But.. I'm still not sure the new name is accurate, either...
>
> [snip]
>>> if (form1_affinity) {
>>> - depth = of_read_number(distance_ref_points, 1);
>>> + index = of_read_number(distance_ref_points, 1);
>
> AFACIT distance_ref_points hasn't been altered from the
> of_get_property() at this point, so isn't this setting depth / index
> to the number of entries in ref-points, rather than the value of the
> first entry (which is what primary domain index is supposed to be).
>
ibm,associativity-reference-points property format is as below.
# lsprop ibm,associativity-reference-points
ibm,associativity-reference-points
00000004 00000002
it doesn't have the number of elements as the first item.
For FORM1 1 element is the NUMA boundary index/primary_domain_index
For FORM0 2 element is the NUMA boundary index/primary_domain_index.
>>> } else {
>>> if (distance_ref_points_depth < 2) {
>>> printk(KERN_WARNING "NUMA: "
>>> @@ -334,7 +334,7 @@ static int __init find_min_common_depth(void)
>>> goto err;
>>> }
>>>
>>> - depth = of_read_number(&distance_ref_points[1], 1);
>>> + index = of_read_number(&distance_ref_points[1], 1);
>>> }
>>>
>>> /*
>>> @@ -348,7 +348,7 @@ static int __init find_min_common_depth(void)
>>> }
>>>
>>> of_node_put(root);
>>> - return depth;
>>> + return index;
>>>
>>> err:
>>> of_node_put(root);
>>> @@ -437,16 +437,16 @@ int of_drconf_to_nid_single(struct drmem_lmb *lmb)
>>> int nid = default_nid;
>>> int rc, index;
>>>
>>> - if ((min_common_depth < 0) || !numa_enabled)
>>> + if ((primary_domain_index < 0) || !numa_enabled)
>>> return default_nid;
>>>
>>> rc = of_get_assoc_arrays(&aa);
>>> if (rc)
>>> return default_nid;
>>>
>>> - if (min_common_depth <= aa.array_sz &&
>>> + if (primary_domain_index <= aa.array_sz &&
>>> !(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
>>> - index = lmb->aa_index * aa.array_sz + min_common_depth - 1;
>>> + index = lmb->aa_index * aa.array_sz + primary_domain_index - 1;
>>> nid = of_read_number(&aa.arrays[index], 1);
>>>
>>> if (nid == 0xffff || nid >= nr_node_ids)
>>> @@ -708,18 +708,18 @@ static int __init parse_numa_properties(void)
>>> return -1;
>>> }
>>>
>>> - min_common_depth = find_min_common_depth();
>>> + primary_domain_index = find_primary_domain_index();
>>>
>>> - if (min_common_depth < 0) {
>>> + if (primary_domain_index < 0) {
>>> /*
>>> - * if we fail to parse min_common_depth from device tree
>>> + * if we fail to parse primary_domain_index from device tree
>>> * mark the numa disabled, boot with numa disabled.
>>> */
>>> numa_enabled = false;
>>> - return min_common_depth;
>>> + return primary_domain_index;
>>> }
>>>
>>> - dbg("NUMA associativity depth for CPU/Memory: %d\n", min_common_depth);
>>> + dbg("NUMA associativity depth for CPU/Memory: %d\n", primary_domain_index);
>>>
>>> /*
>>> * Even though we connect cpus to numa domains later in SMP
>>> @@ -919,14 +919,14 @@ static void __init find_possible_nodes(void)
>>> goto out;
>>> }
>>>
>>> - max_nodes = of_read_number(&domains[min_common_depth], 1);
>>> + max_nodes = of_read_number(&domains[primary_domain_index], 1);
>>> for (i = 0; i < max_nodes; i++) {
>>> if (!node_possible(i))
>>> node_set(i, node_possible_map);
>>> }
>>>
>>> prop_length /= sizeof(int);
>>> - if (prop_length > min_common_depth + 2)
>>> + if (prop_length > primary_domain_index + 2)
>>> coregroup_enabled = 1;
>>>
>>> out:
>>> @@ -1259,7 +1259,7 @@ int cpu_to_coregroup_id(int cpu)
>>> goto out;
>>>
>>> index = of_read_number(associativity, 1);
>>> - if (index > min_common_depth + 1)
>>> + if (index > primary_domain_index + 1)
>>> return of_read_number(&associativity[index - 1], 1);
>>>
>>> out:
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v5 4/6] powerpc/pseries: Consolidate different NUMA distance update code paths
From: Aneesh Kumar K.V @ 2021-07-22 7:07 UTC (permalink / raw)
To: David Gibson; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <YPjMkQ5W1fSQdzNe@yekko>
David Gibson <david@gibson.dropbear.id.au> writes:
> On Mon, Jun 28, 2021 at 08:41:15PM +0530, Aneesh Kumar K.V wrote:
>> The associativity details of the newly added resourced are collected from
>> the hypervisor via "ibm,configure-connector" rtas call. Update the numa
>> distance details of the newly added numa node after the above call.
>>
>> Instead of updating NUMA distance every time we lookup a node id
>> from the associativity property, add helpers that can be used
>> during boot which does this only once. Also remove the distance
>> update from node id lookup helpers.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/mm/numa.c | 173 +++++++++++++-----
>> arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +
>> .../platforms/pseries/hotplug-memory.c | 2 +
>> arch/powerpc/platforms/pseries/pseries.h | 1 +
>> 4 files changed, 132 insertions(+), 46 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index 0ec16999beef..7b142f79d600 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -208,22 +208,6 @@ int __node_distance(int a, int b)
>> }
>> EXPORT_SYMBOL(__node_distance);
>>
>> -static void initialize_distance_lookup_table(int nid,
>> - const __be32 *associativity)
>> -{
>> - int i;
>> -
>> - if (affinity_form != FORM1_AFFINITY)
>> - return;
>> -
>> - for (i = 0; i < max_associativity_domain_index; i++) {
>> - const __be32 *entry;
>> -
>> - entry = &associativity[be32_to_cpu(distance_ref_points[i]) - 1];
>> - distance_lookup_table[nid][i] = of_read_number(entry, 1);
>> - }
>> -}
>> -
>> /*
>> * Returns nid in the range [0..nr_node_ids], or -1 if no useful NUMA
>> * info is found.
>> @@ -241,15 +225,6 @@ static int associativity_to_nid(const __be32 *associativity)
>> /* POWER4 LPAR uses 0xffff as invalid node */
>> if (nid == 0xffff || nid >= nr_node_ids)
>> nid = NUMA_NO_NODE;
>> -
>> - if (nid > 0 &&
>> - of_read_number(associativity, 1) >= max_associativity_domain_index) {
>> - /*
>> - * Skip the length field and send start of associativity array
>> - */
>> - initialize_distance_lookup_table(nid, associativity + 1);
>> - }
>> -
>> out:
>> return nid;
>> }
>> @@ -287,6 +262,49 @@ int of_node_to_nid(struct device_node *device)
>> }
>> EXPORT_SYMBOL(of_node_to_nid);
>>
>> +static void __initialize_form1_numa_distance(const __be32 *associativity)
>> +{
>> + int i, nid;
>> +
>> + if (affinity_form != FORM1_AFFINITY)
>
> Since this shouldn't be called on a !form1 system, this could be a WARN_ON().
The way we call functions currently, instead of doing
if (affinity_form == FORM1_AFFINITY)
__initialize_form1_numa_distance()
We avoid doing the if check in multiple places. For example
parse_numa_properties will fetch the associativity array to find the
details of online node and set it online. We use the same code path to
initialize distance.
if (__vphn_get_associativity(i, vphn_assoc) == 0) {
nid = associativity_to_nid(vphn_assoc);
__initialize_form1_numa_distance(vphn_assoc);
} else {
cpu = of_get_cpu_node(i, NULL);
BUG_ON(!cpu);
associativity = of_get_associativity(cpu);
if (associativity) {
nid = associativity_to_nid(associativity);
__initialize_form1_numa_distance(associativity);
}
We avoid the the if (affinity_form == FORM1_AFFINITY) check there by
moving the check inside __initialize_form1_numa_distance().
>
>> + return;
>> +
>> + if (of_read_number(associativity, 1) >= primary_domain_index) {
>> + nid = of_read_number(&associativity[primary_domain_index], 1);
>
> This computes the nid from the assoc array independently of
> associativity_to_nid, which doesn't seem like a good idea. Wouldn't
> it be better to call assocaitivity_to_nid(), then make the next bit
> conditional on nid !== NUMA_NO_NODE?
@@ -302,9 +302,8 @@ static void __initialize_form1_numa_distance(const __be32 *associativity)
if (affinity_form != FORM1_AFFINITY)
return;
- if (of_read_number(associativity, 1) >= primary_domain_index) {
- nid = of_read_number(&associativity[primary_domain_index], 1);
-
+ nid = associativity_to_nid(associativity);
+ if (nid != NUMA_NO_NODE) {
for (i = 0; i < distance_ref_points_depth; i++) {
const __be32 *entry;
>
>> +
>> + for (i = 0; i < max_associativity_domain_index; i++) {
>> + const __be32 *entry;
>> +
>> + entry = &associativity[be32_to_cpu(distance_ref_points[i])];
>> + distance_lookup_table[nid][i] = of_read_number(entry, 1);
>> + }
>> + }
>> +}
>> +
>> +static void initialize_form1_numa_distance(struct device_node *node)
>> +{
>> + const __be32 *associativity;
>> +
>> + associativity = of_get_associativity(node);
>> + if (!associativity)
>> + return;
>> +
>> + __initialize_form1_numa_distance(associativity);
>> +}
>> +
>> +/*
>> + * Used to update distance information w.r.t newly added node.
>> + */
>> +void update_numa_distance(struct device_node *node)
>> +{
>> + if (affinity_form == FORM0_AFFINITY)
>> + return;
>> + else if (affinity_form == FORM1_AFFINITY) {
>> + initialize_form1_numa_distance(node);
>> + return;
>> + }
>> +}
>> +
>> static int __init find_primary_domain_index(void)
>> {
>> int index;
>> @@ -433,6 +451,48 @@ static int of_get_assoc_arrays(struct assoc_arrays *aa)
>> return 0;
>> }
>>
>> +static int get_nid_and_numa_distance(struct drmem_lmb *lmb)
>> +{
>> + struct assoc_arrays aa = { .arrays = NULL };
>> + int default_nid = NUMA_NO_NODE;
>> + int nid = default_nid;
>> + int rc, index;
>> +
>> + if ((primary_domain_index < 0) || !numa_enabled)
>
> Under what circumstances could you get primary_domain_index < 0?
IIUC that is to handle failure to parse device tree.
ea9f5b702fe0215188fba2eda117419e4ae90a67
>
>> + return default_nid;
>> +
>> + rc = of_get_assoc_arrays(&aa);
>> + if (rc)
>> + return default_nid;
>> +
>> + if (primary_domain_index <= aa.array_sz &&
>> + !(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
>> + index = lmb->aa_index * aa.array_sz + primary_domain_index - 1;
>
> Does anywhere verify that primary_domain_index <= aa.array_sz?
That is the first part of the check?
>
>> + nid = of_read_number(&aa.arrays[index], 1);
>> +
>> + if (nid == 0xffff || nid >= nr_node_ids)
>> + nid = default_nid;
>> + if (nid > 0 && affinity_form == FORM1_AFFINITY) {
>> + int i;
>> + const __be32 *associativity;
>> +
>> + index = lmb->aa_index * aa.array_sz;
>> + associativity = &aa.arrays[index];
>> + /*
>> + * lookup array associativity entries have different format
>> + * There is no length of the array as the first element.
>
> The difference it very small, and this is not a hot path. Couldn't
> you reduce a chunk of code by prepending aa.array_sz, then re-using
> __initialize_form1_numa_distance. Or even making
> __initialize_form1_numa_distance() take the length as a parameter.
The changes are small but confusing w.r.t how we look at the
associativity-lookup-arrays. The way we interpret associativity array
and associativity lookup array using primary_domain_index is different.
Hence the '-1' in the node lookup here.
index = lmb->aa_index * aa.array_sz + primary_domain_index - 1;
nid = of_read_number(&aa.arrays[index], 1);
>
>> + */
>> + for (i = 0; i < max_associativity_domain_index; i++) {
>> + const __be32 *entry;
>> +
>> + entry = &associativity[be32_to_cpu(distance_ref_points[i]) - 1];
>
> Does anywhere verify that distance_ref_points[i] <= aa.array_size for
> every i?
We do check for
if (primary_domain_index <= aa.array_sz &&
>
>> + distance_lookup_table[nid][i] = of_read_number(entry, 1);
>> + }
>> + }
>> + }
>> + return nid;
>> +}
>> +
>> /*
>> * This is like of_node_to_nid_single() for memory represented in the
>> * ibm,dynamic-reconfiguration-memory node.
>> @@ -458,21 +518,14 @@ int of_drconf_to_nid_single(struct drmem_lmb *lmb)
>>
>> if (nid == 0xffff || nid >= nr_node_ids)
>> nid = default_nid;
>> -
>> - if (nid > 0) {
>> - index = lmb->aa_index * aa.array_sz;
>> - initialize_distance_lookup_table(nid,
>> - &aa.arrays[index]);
>> - }
>> }
>> -
>> return nid;
>> }
>>
>> #ifdef CONFIG_PPC_SPLPAR
>> -static int vphn_get_nid(long lcpu)
>> +
>> +static int __vphn_get_associativity(long lcpu, __be32 *associativity)
>> {
>> - __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
>> long rc, hwid;
>>
>> /*
>> @@ -492,10 +545,22 @@ static int vphn_get_nid(long lcpu)
>>
>> rc = hcall_vphn(hwid, VPHN_FLAG_VCPU, associativity);
>> if (rc == H_SUCCESS)
>> - return associativity_to_nid(associativity);
>> + return 0;
>> }
>>
>> + return -1;
>> +}
>> +
>> +static int vphn_get_nid(long lcpu)
>> +{
>> + __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
>> +
>> +
>> + if (!__vphn_get_associativity(lcpu, associativity))
>> + return associativity_to_nid(associativity);
>> +
>> return NUMA_NO_NODE;
>> +
>> }
>> #else
>> static int vphn_get_nid(long unused)
>> @@ -692,7 +757,7 @@ static int __init numa_setup_drmem_lmb(struct drmem_lmb *lmb,
>> size = read_n_cells(n_mem_size_cells, usm);
>> }
>>
>> - nid = of_drconf_to_nid_single(lmb);
>> + nid = get_nid_and_numa_distance(lmb);
>> fake_numa_create_new_node(((base + size) >> PAGE_SHIFT),
>> &nid);
>> node_set_online(nid);
>> @@ -709,6 +774,7 @@ static int __init parse_numa_properties(void)
>> struct device_node *memory;
>> int default_nid = 0;
>> unsigned long i;
>> + const __be32 *associativity;
>>
>> if (numa_enabled == 0) {
>> printk(KERN_WARNING "NUMA disabled by user\n");
>> @@ -734,18 +800,30 @@ static int __init parse_numa_properties(void)
>> * each node to be onlined must have NODE_DATA etc backing it.
>> */
>> for_each_present_cpu(i) {
>> + __be32 vphn_assoc[VPHN_ASSOC_BUFSIZE];
>> struct device_node *cpu;
>> - int nid = vphn_get_nid(i);
>> + int nid = NUMA_NO_NODE;
>>
>> - /*
>> - * Don't fall back to default_nid yet -- we will plug
>> - * cpus into nodes once the memory scan has discovered
>> - * the topology.
>> - */
>> - if (nid == NUMA_NO_NODE) {
>> + memset(vphn_assoc, 0, VPHN_ASSOC_BUFSIZE * sizeof(__be32));
>
> What's the memset() for? AFAICT you only look at vphn_assoc in the
> branch where __vphn_get_associativity() succeeds.
That was done to match the existing code. We do use a zero filled array
when making that hcall in this code path. I don't see us doing that
everywhere. But didn't want to change that behaviour in this patch.
-static int vphn_get_nid(long lcpu)
+
+static int __vphn_get_associativity(long lcpu, __be32 *associativity)
{
- __be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
long rc, hwid;
>
>> +
>> + if (__vphn_get_associativity(i, vphn_assoc) == 0) {
>> + nid = associativity_to_nid(vphn_assoc);
>> + __initialize_form1_numa_distance(vphn_assoc);
>> + } else {
>> +
>> + /*
>> + * Don't fall back to default_nid yet -- we will plug
>> + * cpus into nodes once the memory scan has discovered
>> + * the topology.
>> + */
>> cpu = of_get_cpu_node(i, NULL);
>> BUG_ON(!cpu);
>> - nid = of_node_to_nid_single(cpu);
>> +
>> + associativity = of_get_associativity(cpu);
>> + if (associativity) {
>> + nid = associativity_to_nid(associativity);
>> + __initialize_form1_numa_distance(associativity);
>> + }
>> of_node_put(cpu);
>> }
>>
>> @@ -781,8 +859,11 @@ static int __init parse_numa_properties(void)
>> * have associativity properties. If none, then
>> * everything goes to default_nid.
>> */
>> - nid = of_node_to_nid_single(memory);
>> - if (nid < 0)
>> + associativity = of_get_associativity(memory);
>> + if (associativity) {
>> + nid = associativity_to_nid(associativity);
>> + __initialize_form1_numa_distance(associativity);
>> + } else
>> nid = default_nid;
>>
>> fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
>> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> index 7e970f81d8ff..778b6ab35f0d 100644
>> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
>> @@ -498,6 +498,8 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
>> return saved_rc;
>> }
>>
>> + update_numa_distance(dn);
>> +
>> rc = dlpar_online_cpu(dn);
>> if (rc) {
>> saved_rc = rc;
>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> index 36f66556a7c6..40d350f31a34 100644
>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> @@ -180,6 +180,8 @@ static int update_lmb_associativity_index(struct drmem_lmb *lmb)
>> return -ENODEV;
>> }
>>
>> + update_numa_distance(lmb_node);
>> +
>> dr_node = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> if (!dr_node) {
>> dlpar_free_cc_nodes(lmb_node);
>> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
>> index 1f051a786fb3..663a0859cf13 100644
>> --- a/arch/powerpc/platforms/pseries/pseries.h
>> +++ b/arch/powerpc/platforms/pseries/pseries.h
>> @@ -113,4 +113,5 @@ extern u32 pseries_security_flavor;
>> void pseries_setup_security_mitigations(void);
>> void pseries_lpar_read_hblkrm_characteristics(void);
>>
>> +void update_numa_distance(struct device_node *node);
>> #endif /* _PSERIES_PSERIES_H */
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v5 5/6] powerpc/pseries: Add a helper for form1 cpu distance
From: Aneesh Kumar K.V @ 2021-07-22 7:09 UTC (permalink / raw)
To: David Gibson; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <YPjM/5/KdKs4MNj1@yekko>
David Gibson <david@gibson.dropbear.id.au> writes:
> On Mon, Jun 28, 2021 at 08:41:16PM +0530, Aneesh Kumar K.V wrote:
>> This helper is only used with the dispatch trace log collection.
>> A later patch will add Form2 affinity support and this change helps
>> in keeping that simpler. Also add a comment explaining we don't expect
>> the code to be called with FORM0
>>
>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
> What makes it a "relative_distance" rather than just a "distance"?
I added that to indicate that the function is not returning the actual
distance but a number indicative of 'near', 'far' etc. (it actually returns
1, 2 etc).
>
>> ---
>> arch/powerpc/include/asm/topology.h | 4 ++--
>> arch/powerpc/mm/numa.c | 10 +++++++++-
>> arch/powerpc/platforms/pseries/lpar.c | 4 ++--
>> 3 files changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
>> index e4db64c0e184..ac8b5ed79832 100644
>> --- a/arch/powerpc/include/asm/topology.h
>> +++ b/arch/powerpc/include/asm/topology.h
>> @@ -36,7 +36,7 @@ static inline int pcibus_to_node(struct pci_bus *bus)
>> cpu_all_mask : \
>> cpumask_of_node(pcibus_to_node(bus)))
>>
>> -extern int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc);
>> +int cpu_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc);
>> extern int __node_distance(int, int);
>> #define node_distance(a, b) __node_distance(a, b)
>>
>> @@ -83,7 +83,7 @@ static inline void sysfs_remove_device_from_node(struct device *dev,
>>
>> static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) {}
>>
>> -static inline int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> +static inline int cpu_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> {
>> return 0;
>> }
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index 7b142f79d600..c6293037a103 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -166,7 +166,7 @@ static void unmap_cpu_from_node(unsigned long cpu)
>> }
>> #endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
>>
>> -int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> +static int __cpu_form1_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> {
>> int dist = 0;
>>
>> @@ -182,6 +182,14 @@ int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> return dist;
>> }
>>
>> +int cpu_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> +{
>> + /* We should not get called with FORM0 */
>> + VM_WARN_ON(affinity_form == FORM0_AFFINITY);
>> +
>> + return __cpu_form1_relative_distance(cpu1_assoc, cpu2_assoc);
>> +}
>> +
>> /* must hold reference to node during call */
>> static const __be32 *of_get_associativity(struct device_node *dev)
>> {
>> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
>> index dab356e3ff87..afefbdfe768d 100644
>> --- a/arch/powerpc/platforms/pseries/lpar.c
>> +++ b/arch/powerpc/platforms/pseries/lpar.c
>> @@ -261,7 +261,7 @@ static int cpu_relative_dispatch_distance(int last_disp_cpu, int cur_disp_cpu)
>> if (!last_disp_cpu_assoc || !cur_disp_cpu_assoc)
>> return -EIO;
>>
>> - return cpu_distance(last_disp_cpu_assoc, cur_disp_cpu_assoc);
>> + return cpu_relative_distance(last_disp_cpu_assoc, cur_disp_cpu_assoc);
>> }
>>
>> static int cpu_home_node_dispatch_distance(int disp_cpu)
>> @@ -281,7 +281,7 @@ static int cpu_home_node_dispatch_distance(int disp_cpu)
>> if (!disp_cpu_assoc || !vcpu_assoc)
>> return -EIO;
>>
>> - return cpu_distance(disp_cpu_assoc, vcpu_assoc);
>> + return cpu_relative_distance(disp_cpu_assoc, vcpu_assoc);
>> }
>>
>> static void update_vcpu_disp_stat(int disp_cpu)
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v5 6/6] powerpc/pseries: Add support for FORM2 associativity
From: Aneesh Kumar K.V @ 2021-07-22 7:34 UTC (permalink / raw)
To: David Gibson; +Cc: Nathan Lynch, Daniel Henrique Barboza, linuxppc-dev
In-Reply-To: <YPjX5BxRKj6SFyCW@yekko>
David Gibson <david@gibson.dropbear.id.au> writes:
> On Mon, Jun 28, 2021 at 08:41:17PM +0530, Aneesh Kumar K.V wrote:
>> PAPR interface currently supports two different ways of communicating resource
>> grouping details to the OS. These are referred to as Form 0 and Form 1
>> associativity grouping. Form 0 is the older format and is now considered
>> deprecated. This patch adds another resource grouping named FORM2.
>>
>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> Documentation/powerpc/associativity.rst | 103 ++++++++++++++
>> arch/powerpc/include/asm/firmware.h | 3 +-
>> arch/powerpc/include/asm/prom.h | 1 +
>> arch/powerpc/kernel/prom_init.c | 3 +-
>> arch/powerpc/mm/numa.c | 157 ++++++++++++++++++----
>> arch/powerpc/platforms/pseries/firmware.c | 1 +
>> 6 files changed, 242 insertions(+), 26 deletions(-)
>> create mode 100644 Documentation/powerpc/associativity.rst
>>
>> diff --git a/Documentation/powerpc/associativity.rst b/Documentation/powerpc/associativity.rst
>> new file mode 100644
>> index 000000000000..31cc7da2c7a6
>> --- /dev/null
>> +++ b/Documentation/powerpc/associativity.rst
>> @@ -0,0 +1,103 @@
>> +============================
>> +NUMA resource associativity
>> +=============================
>> +
>> +Associativity represents the groupings of the various platform resources into
>> +domains of substantially similar mean performance relative to resources outside
>> +of that domain. Resources subsets of a given domain that exhibit better
>> +performance relative to each other than relative to other resources subsets
>> +are represented as being members of a sub-grouping domain. This performance
>> +characteristic is presented in terms of NUMA node distance within the Linux kernel.
>> +From the platform view, these groups are also referred to as domains.
>
> Pretty hard to decipher, but that's typical for PAPR.
>
>> +PAPR interface currently supports different ways of communicating these resource
>> +grouping details to the OS. These are referred to as Form 0, Form 1 and Form2
>> +associativity grouping. Form 0 is the older format and is now considered deprecated.
>
> Nit: s/older/oldest/ since there are now >2 forms.
updated.
>
>> +Hypervisor indicates the type/form of associativity used via "ibm,architecture-vec-5 property".
>> +Bit 0 of byte 5 in the "ibm,architecture-vec-5" property indicates usage of Form 0 or Form 1.
>> +A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativity
>> +bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used.
>> +
>> +Form 0
>> +-----
>> +Form 0 associativity supports only two NUMA distances (LOCAL and REMOTE).
>> +
>> +Form 1
>> +-----
>> +With Form 1 a combination of ibm,associativity-reference-points, and ibm,associativity
>> +device tree properties are used to determine the NUMA distance between resource groups/domains.
>> +
>> +The “ibm,associativity” property contains a list of one or more numbers (domainID)
>> +representing the resource’s platform grouping domains.
>> +
>> +The “ibm,associativity-reference-points” property contains a list of one or more numbers
>> +(domainID index) that represents the 1 based ordinal in the associativity lists.
>> +The list of domainID indexes represents an increasing hierarchy of resource grouping.
>> +
>> +ex:
>> +{ primary domainID index, secondary domainID index, tertiary domainID index.. }
>> +
>> +Linux kernel uses the domainID at the primary domainID index as the NUMA node id.
>> +Linux kernel computes NUMA distance between two domains by recursively comparing
>> +if they belong to the same higher-level domains. For mismatch at every higher
>> +level of the resource group, the kernel doubles the NUMA distance between the
>> +comparing domains.
>> +
>> +Form 2
>> +-------
>> +Form 2 associativity format adds separate device tree properties representing NUMA node distance
>> +thereby making the node distance computation flexible. Form 2 also allows flexible primary
>> +domain numbering. With numa distance computation now detached from the index value in
>> +"ibm,associativity-reference-points" property, Form 2 allows a large number of primary domain
>> +ids at the same domainID index representing resource groups of different performance/latency
>> +characteristics.
>> +
>> +Hypervisor indicates the usage of FORM2 associativity using bit 2 of byte 5 in the
>> +"ibm,architecture-vec-5" property.
>> +
>> +"ibm,numa-lookup-index-table" property contains a list of one or more numbers representing
>> +the domainIDs present in the system. The offset of the domainID in this property is
>> +used as an index while computing numa distance information via "ibm,numa-distance-table".
>> +
>> +prop-encoded-array: The number N of the domainIDs encoded as with encode-int, followed by
>> +N domainID encoded as with encode-int
>> +
>> +For ex:
>> +"ibm,numa-lookup-index-table" = {4, 0, 8, 250, 252}. The offset of domainID 8 (2) is used when
>> +computing the distance of domain 8 from other domains present in the system. For the rest of
>> +this document, this offset will be referred to as domain distance offset.
>> +
>> +"ibm,numa-distance-table" property contains a list of one or more numbers representing the NUMA
>> +distance between resource groups/domains present in the system.
>> +
>> +prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by
>> +N distance values encoded as with encode-bytes. The max distance value we could encode is 255.
>> +The number N must be equal to the square of m where m is the number of domainIDs in the
>> +numa-lookup-index-table.
>> +
>> +For ex:
>> +ibm,numa-lookup-index-table = {3, 0, 8, 40}
>> +ibm,numa-distance-table = {9, 10, 20, 80, 20, 10, 160, 80, 160, 10}
>
> This representation doesn't make it clear that the 9 is a u32, but the
> rest are u8s.
How do you suggest we specify that? I could do 9:u32 10:u8 etc. But
considering the details are explained in the paragraph above, is that
needed?
>
>> +
>> + | 0 8 40
>> +--|------------
>> + |
>> +0 | 10 20 80
>> + |
>> +8 | 20 10 160
>> + |
>> +40| 80 160 10
>> +
>> +A possible "ibm,associativity" property for resources in node 0, 8 and 40
>> +
>> +{ 3, 6, 7, 0 }
>> +{ 3, 6, 9, 8 }
>> +{ 3, 6, 7, 40}
>> +
>> +With "ibm,associativity-reference-points" { 0x3 }
>
> You haven't actually described how ibm,associativity-reference-points
> operates in Form2.
Nothing change w.r.t the definition of associativity-reference-points
w.r.t FORM2. It still will continue to show the increasing hierarchy of
resource groups.
>
>> +"ibm,lookup-index-table" helps in having a compact representation of distance matrix.
>> +Since domainID can be sparse, the matrix of distances can also be effectively sparse.
>> +With "ibm,lookup-index-table" we can achieve a compact representation of
>> +distance information.
>> diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
>> index 60b631161360..97a3bd9ffeb9 100644
>> --- a/arch/powerpc/include/asm/firmware.h
>> +++ b/arch/powerpc/include/asm/firmware.h
>> @@ -53,6 +53,7 @@
>> #define FW_FEATURE_ULTRAVISOR ASM_CONST(0x0000004000000000)
>> #define FW_FEATURE_STUFF_TCE ASM_CONST(0x0000008000000000)
>> #define FW_FEATURE_RPT_INVALIDATE ASM_CONST(0x0000010000000000)
>> +#define FW_FEATURE_FORM2_AFFINITY ASM_CONST(0x0000020000000000)
>>
>> #ifndef __ASSEMBLY__
>>
>> @@ -73,7 +74,7 @@ enum {
>> FW_FEATURE_HPT_RESIZE | FW_FEATURE_DRMEM_V2 |
>> FW_FEATURE_DRC_INFO | FW_FEATURE_BLOCK_REMOVE |
>> FW_FEATURE_PAPR_SCM | FW_FEATURE_ULTRAVISOR |
>> - FW_FEATURE_RPT_INVALIDATE,
>> + FW_FEATURE_RPT_INVALIDATE | FW_FEATURE_FORM2_AFFINITY,
>> FW_FEATURE_PSERIES_ALWAYS = 0,
>> FW_FEATURE_POWERNV_POSSIBLE = FW_FEATURE_OPAL | FW_FEATURE_ULTRAVISOR,
>> FW_FEATURE_POWERNV_ALWAYS = 0,
>> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
>> index df9fec9d232c..5c80152e8f18 100644
>> --- a/arch/powerpc/include/asm/prom.h
>> +++ b/arch/powerpc/include/asm/prom.h
>> @@ -149,6 +149,7 @@ extern int of_read_drc_info_cell(struct property **prop,
>> #define OV5_XCMO 0x0440 /* Page Coalescing */
>> #define OV5_FORM1_AFFINITY 0x0580 /* FORM1 NUMA affinity */
>> #define OV5_PRRN 0x0540 /* Platform Resource Reassignment */
>> +#define OV5_FORM2_AFFINITY 0x0520 /* Form2 NUMA affinity */
>> #define OV5_HP_EVT 0x0604 /* Hot Plug Event support */
>> #define OV5_RESIZE_HPT 0x0601 /* Hash Page Table resizing */
>> #define OV5_PFO_HW_RNG 0x1180 /* PFO Random Number Generator */
>> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
>> index 5d9ea059594f..c483df6c9393 100644
>> --- a/arch/powerpc/kernel/prom_init.c
>> +++ b/arch/powerpc/kernel/prom_init.c
>> @@ -1069,7 +1069,8 @@ static const struct ibm_arch_vec ibm_architecture_vec_template __initconst = {
>> #else
>> 0,
>> #endif
>> - .associativity = OV5_FEAT(OV5_FORM1_AFFINITY) | OV5_FEAT(OV5_PRRN),
>> + .associativity = OV5_FEAT(OV5_FORM1_AFFINITY) | OV5_FEAT(OV5_PRRN) |
>> + OV5_FEAT(OV5_FORM2_AFFINITY),
>> .bin_opts = OV5_FEAT(OV5_RESIZE_HPT) | OV5_FEAT(OV5_HP_EVT),
>> .micro_checkpoint = 0,
>> .reserved0 = 0,
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index c6293037a103..c68846fc9550 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -56,12 +56,17 @@ static int n_mem_addr_cells, n_mem_size_cells;
>>
>> #define FORM0_AFFINITY 0
>> #define FORM1_AFFINITY 1
>> +#define FORM2_AFFINITY 2
>> static int affinity_form;
>>
>> #define MAX_DISTANCE_REF_POINTS 4
>> static int max_associativity_domain_index;
>> static const __be32 *distance_ref_points;
>> static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
>> +static int numa_distance_table[MAX_NUMNODES][MAX_NUMNODES] = {
>> + [0 ... MAX_NUMNODES - 1] = { [0 ... MAX_NUMNODES - 1] = -1 }
>> +};
>> +static int numa_id_index_table[MAX_NUMNODES] = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };
>>
>> /*
>> * Allocate node_to_cpumask_map based on number of available nodes
>> @@ -166,6 +171,44 @@ static void unmap_cpu_from_node(unsigned long cpu)
>> }
>> #endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
>>
>> +/*
>> + * Returns nid in the range [0..nr_node_ids], or -1 if no useful NUMA
>> + * info is found.
>> + */
>> +static int associativity_to_nid(const __be32 *associativity)
>> +{
>> + int nid = NUMA_NO_NODE;
>> +
>> + if (!numa_enabled)
>> + goto out;
>> +
>> + if (of_read_number(associativity, 1) >= primary_domain_index)
>> + nid = of_read_number(&associativity[primary_domain_index], 1);
>> +
>> + /* POWER4 LPAR uses 0xffff as invalid node */
>> + if (nid == 0xffff || nid >= nr_node_ids)
>> + nid = NUMA_NO_NODE;
>> +out:
>> + return nid;
>> +}
>> +
>> +static int __cpu_form2_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> +{
>> + int dist;
>> + int node1, node2;
>> +
>> + node1 = associativity_to_nid(cpu1_assoc);
>> + node2 = associativity_to_nid(cpu2_assoc);
>> +
>> + dist = numa_distance_table[node1][node2];
>> + if (dist <= LOCAL_DISTANCE)
>> + return 0;
>> + else if (dist <= REMOTE_DISTANCE)
>> + return 1;
>> + else
>> + return 2;
>
> Squashing the full range of distances into just 0, 1 or 2 seems odd.
> But then, this whole cpu_distance() thing being distinct from
> node_distance() seems odd.
>
>> +}
>> +
>> static int __cpu_form1_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> {
>> int dist = 0;
>> @@ -186,8 +229,9 @@ int cpu_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
>> {
>> /* We should not get called with FORM0 */
>> VM_WARN_ON(affinity_form == FORM0_AFFINITY);
>> -
>> - return __cpu_form1_relative_distance(cpu1_assoc, cpu2_assoc);
>> + if (affinity_form == FORM1_AFFINITY)
>> + return __cpu_form1_relative_distance(cpu1_assoc, cpu2_assoc);
>> + return __cpu_form2_relative_distance(cpu1_assoc, cpu2_assoc);
>> }
>>
>> /* must hold reference to node during call */
>> @@ -201,7 +245,9 @@ int __node_distance(int a, int b)
>> int i;
>> int distance = LOCAL_DISTANCE;
>>
>> - if (affinity_form == FORM0_AFFINITY)
>> + if (affinity_form == FORM2_AFFINITY)
>> + return numa_distance_table[a][b];
>> + else if (affinity_form == FORM0_AFFINITY)
>> return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);
>>
>> for (i = 0; i < max_associativity_domain_index; i++) {
>
> Hmm.. couldn't we simplify this whole __node_distance function, if we
> just update numa_distance_table[][] appropriately for Form0 and Form1
> as well?
IIUC what you are suggesting is to look at the possibility of using
numa_distance_table[a][b] even for FORM1_AFFINITY? I can do that as part
of separate patch?
>
>> @@ -216,27 +262,6 @@ int __node_distance(int a, int b)
>> }
>> EXPORT_SYMBOL(__node_distance);
>>
>> -/*
>> - * Returns nid in the range [0..nr_node_ids], or -1 if no useful NUMA
>> - * info is found.
>> - */
>> -static int associativity_to_nid(const __be32 *associativity)
>> -{
>> - int nid = NUMA_NO_NODE;
>> -
>> - if (!numa_enabled)
>> - goto out;
>> -
>> - if (of_read_number(associativity, 1) >= primary_domain_index)
>> - nid = of_read_number(&associativity[primary_domain_index], 1);
>> -
>> - /* POWER4 LPAR uses 0xffff as invalid node */
>> - if (nid == 0xffff || nid >= nr_node_ids)
>> - nid = NUMA_NO_NODE;
>> -out:
>> - return nid;
>> -}
>> -
>> /* Returns the nid associated with the given device tree node,
>> * or -1 if not found.
>> */
>> @@ -305,12 +330,84 @@ static void initialize_form1_numa_distance(struct device_node *node)
>> */
>> void update_numa_distance(struct device_node *node)
>> {
>> + int nid;
>> +
>> if (affinity_form == FORM0_AFFINITY)
>> return;
>> else if (affinity_form == FORM1_AFFINITY) {
>> initialize_form1_numa_distance(node);
>> return;
>> }
>> +
>> + /* FORM2 affinity */
>> + nid = of_node_to_nid_single(node);
>> + if (nid == NUMA_NO_NODE)
>> + return;
>> +
>> + /*
>> + * With FORM2 we expect NUMA distance of all possible NUMA
>> + * nodes to be provided during boot.
>> + */
>> + WARN(numa_distance_table[nid][nid] == -1,
>> + "NUMA distance details for node %d not provided\n", nid);
>> +}
>> +
>> +/*
>> + * ibm,numa-lookup-index-table= {N, domainid1, domainid2, ..... domainidN}
>> + * ibm,numa-distance-table = { N, 1, 2, 4, 5, 1, 6, .... N elements}
>> + */
>> +static void initialize_form2_numa_distance_lookup_table(struct device_node *root)
>> +{
>> + int i, j;
>> + const __u8 *numa_dist_table;
>> + const __be32 *numa_lookup_index;
>> + int numa_dist_table_length;
>> + int max_numa_index, distance_index;
>> +
>> + numa_lookup_index = of_get_property(root, "ibm,numa-lookup-index-table", NULL);
>> + max_numa_index = of_read_number(&numa_lookup_index[0], 1);
>> +
>> + /* first element of the array is the size and is encode-int */
>> + numa_dist_table = of_get_property(root, "ibm,numa-distance-table", NULL);
>> + numa_dist_table_length = of_read_number((const __be32 *)&numa_dist_table[0], 1);
>> + /* Skip the size which is encoded int */
>> + numa_dist_table += sizeof(__be32);
>> +
>> + pr_debug("numa_dist_table_len = %d, numa_dist_indexes_len = %d\n",
>> + numa_dist_table_length, max_numa_index);
>> +
>> + for (i = 0; i < max_numa_index; i++)
>> + /* +1 skip the max_numa_index in the property */
>> + numa_id_index_table[i] = of_read_number(&numa_lookup_index[i + 1], 1);
>> +
>> +
>> + if (numa_dist_table_length != max_numa_index * max_numa_index) {
>> +
>> + WARN(1, "Wrong NUMA distance information\n");
>> + /* consider everybody else just remote. */
>> + for (i = 0; i < max_numa_index; i++) {
>> + for (j = 0; j < max_numa_index; j++) {
>> + int nodeA = numa_id_index_table[i];
>> + int nodeB = numa_id_index_table[j];
>> +
>> + if (nodeA == nodeB)
>> + numa_distance_table[nodeA][nodeB] = LOCAL_DISTANCE;
>> + else
>> + numa_distance_table[nodeA][nodeB] = REMOTE_DISTANCE;
>> + }
>> + }
>> + }
>> +
>> + distance_index = 0;
>> + for (i = 0; i < max_numa_index; i++) {
>> + for (j = 0; j < max_numa_index; j++) {
>> + int nodeA = numa_id_index_table[i];
>> + int nodeB = numa_id_index_table[j];
>> +
>> + numa_distance_table[nodeA][nodeB] = numa_dist_table[distance_index++];
>> + pr_debug("dist[%d][%d]=%d ", nodeA, nodeB, numa_distance_table[nodeA][nodeB]);
>> + }
>> + }
>> }
>>
>> static int __init find_primary_domain_index(void)
>> @@ -323,6 +420,9 @@ static int __init find_primary_domain_index(void)
>> */
>> if (firmware_has_feature(FW_FEATURE_OPAL)) {
>> affinity_form = FORM1_AFFINITY;
>> + } else if (firmware_has_feature(FW_FEATURE_FORM2_AFFINITY)) {
>> + dbg("Using form 2 affinity\n");
>> + affinity_form = FORM2_AFFINITY;
>> } else if (firmware_has_feature(FW_FEATURE_FORM1_AFFINITY)) {
>> dbg("Using form 1 affinity\n");
>> affinity_form = FORM1_AFFINITY;
>> @@ -367,8 +467,17 @@ static int __init find_primary_domain_index(void)
>>
>> index = of_read_number(&distance_ref_points[1], 1);
>> } else {
>> + /*
>> + * Both FORM1 and FORM2 affinity find the primary domain details
>> + * at the same offset.
>> + */
>> index = of_read_number(distance_ref_points, 1);
>> }
>> + /*
>> + * If it is FORM2 also initialize the distance table here.
>> + */
>> + if (affinity_form == FORM2_AFFINITY)
>> + initialize_form2_numa_distance_lookup_table(root);
>
> Ew. Calling a function called "find_primary_domain_index" to also
> initialize the main distance table is needlessly counterintuitive.
> Move this call to parse_numa_properties().
The reason I ended up doing it here is because 'root' is already fetched
here. But I agree it is confusing. I will move fetching of root inside
initialize_form2_numa_distance_lookup_table() and move the function
outside primary_index lookup.
modified arch/powerpc/mm/numa.c
@@ -355,14 +355,22 @@ void update_numa_distance(struct device_node *node)
* ibm,numa-lookup-index-table= {N, domainid1, domainid2, ..... domainidN}
* ibm,numa-distance-table = { N, 1, 2, 4, 5, 1, 6, .... N elements}
*/
-static void initialize_form2_numa_distance_lookup_table(struct device_node *root)
+static void initialize_form2_numa_distance_lookup_table()
{
int i, j;
+ struct device_node *root;
const __u8 *numa_dist_table;
const __be32 *numa_lookup_index;
int numa_dist_table_length;
int max_numa_index, distance_index;
+ if (firmware_has_feature(FW_FEATURE_OPAL))
+ root = of_find_node_by_path("/ibm,opal");
+ else
+ root = of_find_node_by_path("/rtas");
+ if (!root)
+ root = of_find_node_by_path("/");
+
numa_lookup_index = of_get_property(root, "ibm,numa-lookup-index-table", NULL);
max_numa_index = of_read_number(&numa_lookup_index[0], 1);
@@ -407,6 +415,7 @@ static void initialize_form2_numa_distance_lookup_table(struct device_node *root
pr_debug("dist[%d][%d]=%d ", nodeA, nodeB, numa_distance_table[nodeA][nodeB]);
}
}
+ of_node_put(root);
}
static int __init find_primary_domain_index(void)
@@ -472,12 +481,6 @@ static int __init find_primary_domain_index(void)
*/
index = of_read_number(distance_ref_points, 1);
}
- /*
- * If it is FORM2 also initialize the distance table here.
- */
- if (affinity_form == FORM2_AFFINITY)
- initialize_form2_numa_distance_lookup_table(root);
-
/*
* Warn and cap if the hardware supports more than
* MAX_DISTANCE_REF_POINTS domains.
@@ -916,6 +919,12 @@ static int __init parse_numa_properties(void)
dbg("NUMA associativity depth for CPU/Memory: %d\n", primary_domain_index);
+ /*
+ * If it is FORM2 also initialize the distance table here.
+ */
+ if (affinity_form == FORM2_AFFINITY)
+ initialize_form2_numa_distance_lookup_table();
+
/*
* Even though we connect cpus to numa domains later in SMP
* init, we need to know the node ids now. This is because
-aneesh
^ permalink raw reply
* Re: [PATCH v4 0/5] bus: Make remove callback return void
From: Greg Kroah-Hartman @ 2021-07-22 8:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: nvdimm, linux-sh, Samuel Iglesias Gonsalvez, Jens Taprogge,
Ulf Hansson, Jaroslav Kysela, Benjamin Tissoires, Paul Mackerras,
Srinivas Pandruvada, K. Y. Srinivasan, Mike Christie, Wei Liu,
Maxim Levitsky, Samuel Holland, Halil Pasic, linux-acpi,
Geert Uytterhoeven, linux-pci, xen-devel, Tomas Winkler,
Julien Grall, Ohad Ben-Cohen, Yufen Yu, Alex Williamson,
Alex Elder, linux-parisc, Finn Thain, Geoff Levand, linux-fpga,
linux-usb, Rafael J. Wysocki, linux-kernel, linux-spi,
Kai-Heng Feng, kernel, Jon Mason, linux-ntb, Wu Hao,
David Woodhouse, Krzysztof Wilczyński, Alexandre Belloni,
Manohar Vanga, Matthew Rosato, linux-wireless, Dominik Brodowski,
virtualization, James E.J. Bottomley, target-devel,
Srinivas Kandagatla, linux-i2c, linux-s390, Stefano Stabellini,
Stephen Hemminger, Yoshinori Sato, Jiri Slaby, Helge Deller,
Rafał Miłecki, YueHaibing, industrypack-devel,
linux-mips, Len Brown, Eric Farman, Vasily Gorbik, linux-arm-msm,
linux-media, Maxime Ripard, William Breathitt Gray, greybus-dev,
linux-m68k, Florian Fainelli, Rikard Falkeborn, Frank Li,
Mark Gross, Boris Ostrovsky, Mika Westerberg, linux-arm-kernel,
Johannes Thumshirn, Mathieu Poirier, Stephen Boyd, Cornelia Huck,
Peter Oberparleiter, Wolfram Sang, Joey Pabalan, Yehezkel Bernat,
Pali Rohár, Bodo Stroesser, Alison Schofield,
Heikki Krogerus, Tyrel Datwyler, Alexander Shishkin, Tom Rix,
Jason Wang, SeongJae Park, alsa-devel, platform-driver-x86,
Bjorn Helgaas, netdev, Vineeth Vijayan, Ira Weiny, Rob Herring,
Lorenzo Pieralisi, Dave Jiang, linux-staging, Dexuan Cui,
Jernej Skrabec, Kishon Vijay Abraham I, Christian Borntraeger,
Chen-Yu Tsai, linux-input, Allen Hubbe, Alex Dubov, Haiyang Zhang,
Jiri Kosina, Russell King (Oracle), Ben Widawsky,
Harald Freudenberger, linux-cxl, Michael Buesch, Dan Williams,
Mauro Carvalho Chehab, Cristian Marussi, Thomas Bogendoerfer,
Martin K. Petersen, Martyn Welch, Dmitry Torokhov, linux-mmc,
linux-sunxi, Stefan Richter, Sudeep Holla, David S. Miller,
Sven Van Asbroeck, Rich Felker, kvm, Michael S. Tsirkin,
linux-remoteproc, Bjorn Andersson, sparclinux, Kirti Wankhede,
Andreas Noever, linux-i3c, linux1394-devel, Lee Jones,
Arnd Bergmann, linux-scsi, Marc Zyngier, Russell King,
Thorsten Scherer, Andy Gross, linux-serial, Jakub Kicinski,
linux-hyperv, Michael Jamet, Heiko Carstens, Johan Hovold,
Hans de Goede, Hannes Reinecke, Juergen Gross, linuxppc-dev,
Takashi Iwai, Alexandre Bounine, Vinod Koul, Mark Brown,
Vishal Verma, dmaengine, Moritz Fischer, Johannes Berg,
Maximilian Luz
In-Reply-To: <YPfyZen4Y0uDKqDT@kroah.com>
On Wed, Jul 21, 2021 at 12:09:41PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this is v4 of the final patch set for my effort to make struct
> > bus_type::remove return void.
> >
> > The first four patches contain cleanups that make some of these
> > callbacks (more obviously) always return 0. They are acked by the
> > respective maintainers. Bjorn Helgaas explicitly asked to include the
> > pci patch (#1) into this series, so Greg taking this is fine. I assume
> > the s390 people are fine with Greg taking patches #2 to #4, too, they
> > didn't explicitly said so though.
> >
> > The last patch actually changes the prototype and so touches quite some
> > drivers and has the potential to conflict with future developments, so I
> > consider it beneficial to put these patches into next soon. I expect
> > that it will be Greg who takes the complete series, he already confirmed
> > via irc (for v2) to look into this series.
> >
> > The only change compared to v3 is in the fourth patch where I modified a
> > few more drivers to fix build failures. Some of them were found by build
> > bots (thanks!), some of them I found myself using a regular expression
> > search. The newly modified files are:
> >
> > arch/sparc/kernel/vio.c
> > drivers/nubus/bus.c
> > drivers/sh/superhyway/superhyway.c
> > drivers/vlynq/vlynq.c
> > drivers/zorro/zorro-driver.c
> > sound/ac97/bus.c
> >
> > Best regards
> > Uwe
>
> Now queued up. I can go make a git tag that people can pull from after
> 0-day is finished testing this to verify all is good, if others need it.
Ok, here's a tag that any other subsystem can pull from if they want
these changes in their tree before 5.15-rc1 is out. I might pull it
into my char-misc-next tree as well just to keep that tree sane as it
seems to pick up new busses on a regular basis...
thanks,
greg k-h
-----------------------------------
The following changes since commit 2734d6c1b1a089fb593ef6a23d4b70903526fe0c:
Linux 5.14-rc2 (2021-07-18 14:13:49 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/bus_remove_return_void-5.15
for you to fetch changes up to fc7a6209d5710618eb4f72a77cd81b8d694ecf89:
bus: Make remove callback return void (2021-07-21 11:53:42 +0200)
----------------------------------------------------------------
Bus: Make remove callback return void tag
Tag for other trees/branches to pull from in order to have a stable
place to build off of if they want to add new busses for 5.15.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Uwe Kleine-König (5):
PCI: endpoint: Make struct pci_epf_driver::remove return void
s390/cio: Make struct css_driver::remove return void
s390/ccwgroup: Drop if with an always false condition
s390/scm: Make struct scm_driver::remove return void
bus: Make remove callback return void
arch/arm/common/locomo.c | 3 +--
arch/arm/common/sa1111.c | 4 +---
arch/arm/mach-rpc/ecard.c | 4 +---
arch/mips/sgi-ip22/ip22-gio.c | 3 +--
arch/parisc/kernel/drivers.c | 5 ++---
arch/powerpc/platforms/ps3/system-bus.c | 3 +--
arch/powerpc/platforms/pseries/ibmebus.c | 3 +--
arch/powerpc/platforms/pseries/vio.c | 3 +--
arch/s390/include/asm/eadm.h | 2 +-
arch/sparc/kernel/vio.c | 4 +---
drivers/acpi/bus.c | 3 +--
drivers/amba/bus.c | 4 +---
drivers/base/auxiliary.c | 4 +---
drivers/base/isa.c | 4 +---
drivers/base/platform.c | 4 +---
drivers/bcma/main.c | 6 ++----
drivers/bus/sunxi-rsb.c | 4 +---
drivers/cxl/core.c | 3 +--
drivers/dax/bus.c | 4 +---
drivers/dma/idxd/sysfs.c | 4 +---
drivers/firewire/core-device.c | 4 +---
drivers/firmware/arm_scmi/bus.c | 4 +---
drivers/firmware/google/coreboot_table.c | 4 +---
drivers/fpga/dfl.c | 4 +---
drivers/hid/hid-core.c | 4 +---
drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +---
drivers/hv/vmbus_drv.c | 5 +----
drivers/hwtracing/intel_th/core.c | 4 +---
drivers/i2c/i2c-core-base.c | 5 +----
drivers/i3c/master.c | 4 +---
drivers/input/gameport/gameport.c | 3 +--
drivers/input/serio/serio.c | 3 +--
drivers/ipack/ipack.c | 4 +---
drivers/macintosh/macio_asic.c | 4 +---
drivers/mcb/mcb-core.c | 4 +---
drivers/media/pci/bt8xx/bttv-gpio.c | 3 +--
drivers/memstick/core/memstick.c | 3 +--
drivers/mfd/mcp-core.c | 3 +--
drivers/misc/mei/bus.c | 4 +---
drivers/misc/tifm_core.c | 3 +--
drivers/mmc/core/bus.c | 4 +---
drivers/mmc/core/sdio_bus.c | 4 +---
drivers/net/netdevsim/bus.c | 3 +--
drivers/ntb/core.c | 4 +---
drivers/ntb/ntb_transport.c | 4 +---
drivers/nubus/bus.c | 6 ++----
drivers/nvdimm/bus.c | 3 +--
drivers/pci/endpoint/pci-epf-core.c | 7 ++-----
drivers/pci/pci-driver.c | 3 +--
drivers/pcmcia/ds.c | 4 +---
drivers/platform/surface/aggregator/bus.c | 4 +---
drivers/platform/x86/wmi.c | 4 +---
drivers/pnp/driver.c | 3 +--
drivers/rapidio/rio-driver.c | 4 +---
drivers/rpmsg/rpmsg_core.c | 7 ++-----
drivers/s390/block/scm_drv.c | 4 +---
drivers/s390/cio/ccwgroup.c | 6 +-----
drivers/s390/cio/chsc_sch.c | 3 +--
drivers/s390/cio/css.c | 7 +++----
drivers/s390/cio/css.h | 2 +-
drivers/s390/cio/device.c | 9 +++------
drivers/s390/cio/eadm_sch.c | 4 +---
drivers/s390/cio/scm.c | 5 +++--
drivers/s390/cio/vfio_ccw_drv.c | 3 +--
drivers/s390/crypto/ap_bus.c | 4 +---
drivers/scsi/scsi_debug.c | 3 +--
drivers/sh/superhyway/superhyway.c | 8 ++------
drivers/siox/siox-core.c | 4 +---
drivers/slimbus/core.c | 4 +---
drivers/soc/qcom/apr.c | 4 +---
drivers/spi/spi.c | 4 +---
drivers/spmi/spmi.c | 3 +--
drivers/ssb/main.c | 4 +---
drivers/staging/fieldbus/anybuss/host.c | 4 +---
drivers/staging/greybus/gbphy.c | 4 +---
drivers/target/loopback/tcm_loop.c | 5 ++---
drivers/thunderbolt/domain.c | 4 +---
drivers/tty/serdev/core.c | 4 +---
drivers/usb/common/ulpi.c | 4 +---
drivers/usb/serial/bus.c | 4 +---
drivers/usb/typec/bus.c | 4 +---
drivers/vdpa/vdpa.c | 4 +---
drivers/vfio/mdev/mdev_driver.c | 4 +---
drivers/virtio/virtio.c | 3 +--
drivers/vlynq/vlynq.c | 4 +---
drivers/vme/vme.c | 4 +---
drivers/xen/xenbus/xenbus.h | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 4 +---
drivers/zorro/zorro-driver.c | 3 +--
include/linux/device/bus.h | 2 +-
include/linux/pci-epf.h | 2 +-
sound/ac97/bus.c | 6 ++----
sound/aoa/soundbus/core.c | 4 +---
93 files changed, 107 insertions(+), 263 deletions(-)
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: convert QE interrupt controller to platform_device
From: Li Yang @ 2021-07-22 19:37 UTC (permalink / raw)
To: Maxim Kochetkov
Cc: saravanak, Greg Kroah-Hartman, lkml, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Zhao Qiang
In-Reply-To: <ec981260-fbe3-5cc4-1da3-dfb2f70f8f85@inbox.ru>
On Mon, Jul 19, 2021 at 1:57 AM Maxim Kochetkov <fido_max@inbox.ru> wrote:
>
> 15.07.2021 01:29, Li Yang wrote:
> > From the original code, this should be type = "qeic". It is not
> > defined in current binding but probably needed for backward
> > compatibility.
>
> I took these strings from this part:
>
> np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
>
> if (!np) {
>
> np = of_find_node_by_type(NULL, "qeic");
>
> if (!np)
>
> return -ENODEV;
>
> }
>
> However I can't find usage of "qeic" in any dts, so I will drop this in V2
It is really a bit hard to find as it is pretty old. But it was
really used up until this commit below in 2008. So probably it will
be better to keep it just for backward compatibility?
commit a2dd70a11d4c9cb8a4e4bb41f53a9b430e08559b
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu Jan 24 18:39:59 2008 +0300
[POWERPC] QE: get rid of most device_types and model
Now we're searching for "fsl,qe", "fsl,qe-muram", "fsl,qe-muram-data"
and "fsl,qe-ic".
Unfortunately it's still impossible to remove device_type = "qe"
from the existing device trees because older u-boots are looking for it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Regards,
Leo
^ permalink raw reply
* [PATCH v4 1/2] KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path
From: Fabiano Rosas @ 2021-07-22 22:12 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20210722221240.2384655-1-farosas@linux.ibm.com>
As one of the arguments of the H_ENTER_NESTED hypercall, the nested
hypervisor (L1) prepares a structure containing the values of various
hypervisor-privileged registers with which it wants the nested guest
(L2) to run. Since the nested HV runs in supervisor mode it needs the
host to write to these registers.
To stop a nested HV manipulating this mechanism and using a nested
guest as a proxy to access a facility that has been made unavailable
to it, we have a routine that sanitises the values of the HV registers
before copying them into the nested guest's vcpu struct.
However, when coming out of the guest the values are copied as they
were back into L1 memory, which means that any sanitisation we did
during guest entry will be exposed to L1 after H_ENTER_NESTED returns.
This patch alters this sanitisation to have effect on the vcpu->arch
registers directly before entering and after exiting the guest,
leaving the structure that is copied back into L1 unchanged (except
when we really want L1 to access the value, e.g the Cause bits of
HFSCR).
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_nested.c | 100 +++++++++++++++-------------
1 file changed, 52 insertions(+), 48 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
index 8543ad538b0c..3804dc50ebe8 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -104,8 +104,17 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
{
struct kvmppc_vcore *vc = vcpu->arch.vcore;
+ /*
+ * When loading the hypervisor-privileged registers to run L2,
+ * we might have used bits from L1 state to restrict what the
+ * L2 state is allowed to be. Since L1 is not allowed to read
+ * the HV registers, do not include these modifications in the
+ * return state.
+ */
+ hr->hfscr = ((~HFSCR_INTR_CAUSE & hr->hfscr) |
+ (HFSCR_INTR_CAUSE & vcpu->arch.hfscr));
+
hr->dpdes = vc->dpdes;
- hr->hfscr = vcpu->arch.hfscr;
hr->purr = vcpu->arch.purr;
hr->spurr = vcpu->arch.spurr;
hr->ic = vcpu->arch.ic;
@@ -134,49 +143,7 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
}
}
-/*
- * This can result in some L0 HV register state being leaked to an L1
- * hypervisor when the hv_guest_state is copied back to the guest after
- * being modified here.
- *
- * There is no known problem with such a leak, and in many cases these
- * register settings could be derived by the guest by observing behaviour
- * and timing, interrupts, etc., but it is an issue to consider.
- */
-static void sanitise_hv_regs(struct kvm_vcpu *vcpu, struct hv_guest_state *hr)
-{
- struct kvmppc_vcore *vc = vcpu->arch.vcore;
- u64 mask;
-
- /*
- * Don't let L1 change LPCR bits for the L2 except these:
- */
- mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
- LPCR_LPES | LPCR_MER;
-
- /*
- * Additional filtering is required depending on hardware
- * and configuration.
- */
- hr->lpcr = kvmppc_filter_lpcr_hv(vcpu->kvm,
- (vc->lpcr & ~mask) | (hr->lpcr & mask));
-
- /*
- * Don't let L1 enable features for L2 which we've disabled for L1,
- * but preserve the interrupt cause field.
- */
- hr->hfscr &= (HFSCR_INTR_CAUSE | vcpu->arch.hfscr);
-
- /* Don't let data address watchpoint match in hypervisor state */
- hr->dawrx0 &= ~DAWRX_HYP;
- hr->dawrx1 &= ~DAWRX_HYP;
-
- /* Don't let completed instruction address breakpt match in HV state */
- if ((hr->ciabr & CIABR_PRIV) == CIABR_PRIV_HYPER)
- hr->ciabr &= ~CIABR_PRIV;
-}
-
-static void restore_hv_regs(struct kvm_vcpu *vcpu, struct hv_guest_state *hr)
+static void restore_hv_regs(struct kvm_vcpu *vcpu, const struct hv_guest_state *hr)
{
struct kvmppc_vcore *vc = vcpu->arch.vcore;
@@ -288,6 +255,43 @@ static int kvmhv_write_guest_state_and_regs(struct kvm_vcpu *vcpu,
sizeof(struct pt_regs));
}
+static void load_l2_hv_regs(struct kvm_vcpu *vcpu,
+ const struct hv_guest_state *l2_hv,
+ const struct hv_guest_state *l1_hv, u64 *lpcr)
+{
+ struct kvmppc_vcore *vc = vcpu->arch.vcore;
+ u64 mask;
+
+ restore_hv_regs(vcpu, l2_hv);
+
+ /*
+ * Don't let L1 change LPCR bits for the L2 except these:
+ */
+ mask = LPCR_DPFD | LPCR_ILE | LPCR_TC | LPCR_AIL | LPCR_LD |
+ LPCR_LPES | LPCR_MER;
+
+ /*
+ * Additional filtering is required depending on hardware
+ * and configuration.
+ */
+ *lpcr = kvmppc_filter_lpcr_hv(vcpu->kvm,
+ (vc->lpcr & ~mask) | (*lpcr & mask));
+
+ /*
+ * Don't let L1 enable features for L2 which we've disabled for L1,
+ * but preserve the interrupt cause field.
+ */
+ vcpu->arch.hfscr = l2_hv->hfscr & (HFSCR_INTR_CAUSE | l1_hv->hfscr);
+
+ /* Don't let data address watchpoint match in hypervisor state */
+ vcpu->arch.dawrx0 = l2_hv->dawrx0 & ~DAWRX_HYP;
+ vcpu->arch.dawrx1 = l2_hv->dawrx1 & ~DAWRX_HYP;
+
+ /* Don't let completed instruction address breakpt match in HV state */
+ if ((l2_hv->ciabr & CIABR_PRIV) == CIABR_PRIV_HYPER)
+ vcpu->arch.ciabr = l2_hv->ciabr & ~CIABR_PRIV;
+}
+
long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
{
long int err, r;
@@ -296,7 +300,7 @@ long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
struct hv_guest_state l2_hv = {0}, saved_l1_hv;
struct kvmppc_vcore *vc = vcpu->arch.vcore;
u64 hv_ptr, regs_ptr;
- u64 hdec_exp;
+ u64 hdec_exp, lpcr;
s64 delta_purr, delta_spurr, delta_ic, delta_vtb;
if (vcpu->kvm->arch.l1_ptcr == 0)
@@ -349,8 +353,8 @@ long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
/* Guest must always run with ME enabled, HV disabled. */
vcpu->arch.shregs.msr = (vcpu->arch.regs.msr | MSR_ME) & ~MSR_HV;
- sanitise_hv_regs(vcpu, &l2_hv);
- restore_hv_regs(vcpu, &l2_hv);
+ lpcr = l2_hv.lpcr;
+ load_l2_hv_regs(vcpu, &l2_hv, &saved_l1_hv, &lpcr);
vcpu->arch.ret = RESUME_GUEST;
vcpu->arch.trap = 0;
@@ -360,7 +364,7 @@ long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
r = RESUME_HOST;
break;
}
- r = kvmhv_run_single_vcpu(vcpu, hdec_exp, l2_hv.lpcr);
+ r = kvmhv_run_single_vcpu(vcpu, hdec_exp, lpcr);
} while (is_kvmppc_resume_guest(r));
/* save L2 state for return */
--
2.29.2
^ permalink raw reply related
* [PATCH v4 2/2] KVM: PPC: Book3S HV: Stop forwarding all HFUs to L1
From: Fabiano Rosas @ 2021-07-22 22:12 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin
In-Reply-To: <20210722221240.2384655-1-farosas@linux.ibm.com>
If the nested hypervisor has no access to a facility because it has
been disabled by the host, it should also not be able to see the
Hypervisor Facility Unavailable that arises from one of its guests
trying to access the facility.
This patch turns a HFU that happened in L2 into a Hypervisor Emulation
Assistance interrupt and forwards it to L1 for handling. The ones that
happened because L1 explicitly disabled the facility for L2 are still
let through, along with the corresponding Cause bits in the HFSCR.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_nested.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
index 3804dc50ebe8..d171a400e4d5 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -99,7 +99,7 @@ static void byteswap_hv_regs(struct hv_guest_state *hr)
hr->dawrx1 = swab64(hr->dawrx1);
}
-static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
+static void save_hv_return_state(struct kvm_vcpu *vcpu,
struct hv_guest_state *hr)
{
struct kvmppc_vcore *vc = vcpu->arch.vcore;
@@ -128,7 +128,7 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
hr->pidr = vcpu->arch.pid;
hr->cfar = vcpu->arch.cfar;
hr->ppr = vcpu->arch.ppr;
- switch (trap) {
+ switch (vcpu->arch.trap) {
case BOOK3S_INTERRUPT_H_DATA_STORAGE:
hr->hdar = vcpu->arch.fault_dar;
hr->hdsisr = vcpu->arch.fault_dsisr;
@@ -137,6 +137,27 @@ static void save_hv_return_state(struct kvm_vcpu *vcpu, int trap,
case BOOK3S_INTERRUPT_H_INST_STORAGE:
hr->asdr = vcpu->arch.fault_gpa;
break;
+ case BOOK3S_INTERRUPT_H_FAC_UNAVAIL:
+ {
+ u8 cause = vcpu->arch.hfscr >> 56;
+
+ WARN_ON_ONCE(cause >= BITS_PER_LONG);
+
+ if (!(hr->hfscr & (1UL << cause)))
+ break;
+
+ /*
+ * We have disabled this facility, so it does not
+ * exist from L1's perspective. Turn it into a HEAI.
+ */
+ vcpu->arch.trap = BOOK3S_INTERRUPT_H_EMUL_ASSIST;
+ kvmppc_load_last_inst(vcpu, INST_GENERIC, &vcpu->arch.emul_inst);
+
+ /* Don't leak the cause field */
+ hr->hfscr &= ~HFSCR_INTR_CAUSE;
+
+ fallthrough;
+ }
case BOOK3S_INTERRUPT_H_EMUL_ASSIST:
hr->heir = vcpu->arch.emul_inst;
break;
@@ -374,7 +395,7 @@ long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
delta_spurr = vcpu->arch.spurr - l2_hv.spurr;
delta_ic = vcpu->arch.ic - l2_hv.ic;
delta_vtb = vc->vtb - l2_hv.vtb;
- save_hv_return_state(vcpu, vcpu->arch.trap, &l2_hv);
+ save_hv_return_state(vcpu, &l2_hv);
/* restore L1 state */
vcpu->arch.nested = NULL;
--
2.29.2
^ permalink raw reply related
* [PATCH v4 0/2] KVM: PPC: Book3S HV: Nested guest state sanitising changes
From: Fabiano Rosas @ 2021-07-22 22:12 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, npiggin
This series still aims to stop contaminating the l2_hv structure with
bits that might have come from L1 state.
Patch 1 makes l2_hv read-only (mostly). It is now only changed when we
explicitly want to pass information to L1.
Patch 2 makes sure that L1 is not forwarded HFU interrupts when the
host has decided to disable any facilities (theoretical for now, since
HFSCR bits are always the same between L1/Ln).
Changes since v3:
- now passing lpcr separately into load_l2_hv_regs to solve the
conflict with commit a19b70abc69a ("KVM: PPC: Book3S HV: Nested move
LPCR sanitising to sanitise_hv_regs");
- patch 2 now forwards a HEAI instead of injecting a Program.
v3:
- removed the sanitise functions;
- moved the entry code into a new load_l2_hv_regs and the exit code
into the existing save_hv_return_state;
- new patch: removes the cause bits when L0 has disabled the
corresponding facility.
https://lkml.kernel.org/r/20210415230948.3563415-1-farosas@linux.ibm.com
v2:
- made the change more generic, not only applies to hfscr anymore;
- sanitisation is now done directly on the vcpu struct, l2_hv is left unchanged.
https://lkml.kernel.org/r/20210406214645.3315819-1-farosas@linux.ibm.com
v1:
https://lkml.kernel.org/r/20210305231055.2913892-1-farosas@linux.ibm.com
Fabiano Rosas (2):
KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path
KVM: PPC: Book3S HV: Stop forwarding all HFUs to L1
arch/powerpc/kvm/book3s_hv_nested.c | 125 +++++++++++++++++-----------
1 file changed, 75 insertions(+), 50 deletions(-)
--
2.29.2
^ permalink raw reply
* Re: [PATCH 1/2] PCI/AER: Disable AER interrupt during suspend
From: Bjorn Helgaas @ 2021-07-22 22:23 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Joerg Roedel,
open list:PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC,
open list:PCI SUBSYSTEM, open list, Lalithambika Krishnakumar,
Alex Williamson, Oliver O'Halloran, Bjorn Helgaas,
Mika Westerberg, Lu Baolu
In-Reply-To: <CAAd53p6VN0ejKHcTRgj8mZ_iApR=KogpVZ-HkvdoZbJ=Yue98g@mail.gmail.com>
On Fri, Feb 05, 2021 at 11:17:32PM +0800, Kai-Heng Feng wrote:
> On Fri, Feb 5, 2021 at 7:28 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > [+cc Alex]
> >
> > On Thu, Jan 28, 2021 at 12:09:37PM +0800, Kai-Heng Feng wrote:
> > > On Thu, Jan 28, 2021 at 4:51 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Thu, Jan 28, 2021 at 01:31:00AM +0800, Kai-Heng Feng wrote:
> > > > > Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> > > > > hint") enables ACS, and some platforms lose its NVMe after resume from
> > > > > firmware:
> > > > > [ 50.947816] pcieport 0000:00:1b.0: DPC: containment event, status:0x1f01 source:0x0000
> > > > > [ 50.947817] pcieport 0000:00:1b.0: DPC: unmasked uncorrectable error detected
> > > > > [ 50.947829] pcieport 0000:00:1b.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Receiver ID)
> > > > > [ 50.947830] pcieport 0000:00:1b.0: device [8086:06ac] error status/mask=00200000/00010000
> > > > > [ 50.947831] pcieport 0000:00:1b.0: [21] ACSViol (First)
> > > > > [ 50.947841] pcieport 0000:00:1b.0: AER: broadcast error_detected message
> > > > > [ 50.947843] nvme nvme0: frozen state error detected, reset controller
> > > > >
> > > > > It happens right after ACS gets enabled during resume.
> > > > >
> > > > > To prevent that from happening, disable AER interrupt and enable it on
> > > > > system suspend and resume, respectively.
> > > >
> > > > Lots of questions here. Maybe this is what we'll end up doing, but I
> > > > am curious about why the error is reported in the first place.
> > > >
> > > > Is this a consequence of the link going down and back up?
> > >
> > > Could be. From the observations, it only happens when firmware suspend
> > > (S3) is used.
> > > Maybe it happens when it's gets powered up, but I don't have equipment
> > > to debug at hardware level.
> > >
> > > If we use non-firmware suspend method, enabling ACS after resume won't
> > > trip AER and DPC.
> > >
> > > > Is it consequence of the device doing a DMA when it shouldn't?
> > >
> > > If it's doing DMA while suspending, the same error should also happen
> > > after NVMe is suspended and before PCIe port suspending.
> > > Furthermore, if non-firmware suspend method is used, there's so such
> > > issue, so less likely to be any DMA operation.
> > >
> > > > Are we doing something in the wrong order during suspend? Or maybe
> > > > resume, since I assume the error is reported during resume?
> > >
> > > Yes the error is reported during resume. The suspend/resume order
> > > seems fine as non-firmware suspend doesn't have this issue.
> >
> > I really feel like we need a better understanding of what's going on
> > here. Disabling the AER interrupt is like closing our eyes and
> > pretending that because we don't see it, it didn't happen.
> >
> > An ACS error is triggered by a DMA, right? I'm assuming an MMIO
> > access from the CPU wouldn't trigger this error. And it sounds like
> > the error is triggered before we even start running the driver after
> > resume.
> >
> > If we're powering up an NVMe device from D3cold and it DMAs before the
> > driver touches it, something would be seriously broken. I doubt
> > that's what's happening. Maybe a device could resume some previously
> > programmed DMA after powering up from D3hot.
>
> I am not that familiar with PCIe ACS/AER/DPC, so I can't really answer
> questions you raised.
> PCIe spec doesn't say the suspend/resume order is also not helping here.
>
> However, I really think it's a system firmware issue.
> I've seen some suspend-to-idle platforms with NVMe can reach D3cold,
> those are unaffected.
Marking both of these as "not applicable" for now because I don't
think we really understand what's going on.
Apparently a DMA occurs during suspend or resume and triggers an ACS
violation. I don't think think such a DMA should occur in the first
place.
Or maybe, since you say the problem happens right after ACS is enabled
during resume, we're doing the ACS enable incorrectly? Although I
would think we should not be doing DMA at the same time we're enabling
ACS, either.
If this really is a system firmware issue, both HP and Dell should
have the knowledge and equipment to figure out what's going on.
> > Or maybe the error occurred on suspend, like if the device wasn't
> > quiesced or something, but we didn't notice it until resume? The
> > AER error status bits are RW1CS, which means they can be preserved
> > across hot/warm/cold resets.
> >
> > Can you instrument the code to see whether the AER error status bit is
> > set before enabling ACS? I'm not sure that merely enabling ACS (I
> > assume you mean pci_std_enable_acs(), where we write PCI_ACS_CTRL)
> > should cause an interrupt for a previously-logged error. I suspect
> > that could happen when enabling *AER*, but I wouldn't think it would
> > happen when enabling *ACS*.
>
> Diff to print AER status:
> https://bugzilla.kernel.org/show_bug.cgi?id=209149#c11
>
> And dmesg:
> https://bugzilla.kernel.org/show_bug.cgi?id=209149#c12
>
> Looks like the read before suspend and after resume are both fine.
>
> >
> > Does this error happen on multiple machines from different vendors?
> > Wondering if it could be a BIOS issue, e.g., BIOS not cleaning up
> > after it did something to cause an error.
>
> AFAIK, systems from both HP and Dell are affected.
> I was told that the reference platform from Intel is using
> suspend-to-idle, but vendors changed the sleep method to S3 to have
> lower power consumption to pass regulation.
>
> Kai-Heng
>
> >
> > > > If we *do* take the error, why doesn't DPC recovery work?
> > >
> > > It works for the root port, but not for the NVMe drive:
> > > [ 50.947816] pcieport 0000:00:1b.0: DPC: containment event,
> > > status:0x1f01 source:0x0000
> > > [ 50.947817] pcieport 0000:00:1b.0: DPC: unmasked uncorrectable error detected
> > > [ 50.947829] pcieport 0000:00:1b.0: PCIe Bus Error:
> > > severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Receiver
> > > ID)
> > > [ 50.947830] pcieport 0000:00:1b.0: device [8086:06ac] error
> > > status/mask=00200000/00010000
> > > [ 50.947831] pcieport 0000:00:1b.0: [21] ACSViol (First)
> > > [ 50.947841] pcieport 0000:00:1b.0: AER: broadcast error_detected message
> > > [ 50.947843] nvme nvme0: frozen state error detected, reset controller
> > > [ 50.948400] ACPI: EC: event unblocked
> > > [ 50.948432] xhci_hcd 0000:00:14.0: PME# disabled
> > > [ 50.948444] xhci_hcd 0000:00:14.0: enabling bus mastering
> > > [ 50.949056] pcieport 0000:00:1b.0: PME# disabled
> > > [ 50.949068] pcieport 0000:00:1c.0: PME# disabled
> > > [ 50.949416] e1000e 0000:00:1f.6: PME# disabled
> > > [ 50.949463] e1000e 0000:00:1f.6: enabling bus mastering
> > > [ 50.951606] sd 0:0:0:0: [sda] Starting disk
> > > [ 50.951610] nvme 0000:01:00.0: can't change power state from D3hot
> > > to D0 (config space inaccessible)
> > > [ 50.951730] nvme nvme0: Removing after probe failure status: -19
> > > [ 50.952360] nvme nvme0: failed to set APST feature (-19)
> > > [ 50.971136] snd_hda_intel 0000:00:1f.3: PME# disabled
> > > [ 51.089330] pcieport 0000:00:1b.0: AER: broadcast resume message
> > > [ 51.089345] pcieport 0000:00:1b.0: AER: device recovery successful
> > >
> > > But I think why recovery doesn't work for NVMe is for another discussion...
> > >
> > > Kai-Heng
> > >
> > > >
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209149
> > > > > Fixes: 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in hint")
> > > > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > > > ---
> > > > > drivers/pci/pcie/aer.c | 18 ++++++++++++++++++
> > > > > 1 file changed, 18 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > > > > index 77b0f2c45bc0..0e9a85530ae6 100644
> > > > > --- a/drivers/pci/pcie/aer.c
> > > > > +++ b/drivers/pci/pcie/aer.c
> > > > > @@ -1365,6 +1365,22 @@ static int aer_probe(struct pcie_device *dev)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static int aer_suspend(struct pcie_device *dev)
> > > > > +{
> > > > > + struct aer_rpc *rpc = get_service_data(dev);
> > > > > +
> > > > > + aer_disable_rootport(rpc);
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static int aer_resume(struct pcie_device *dev)
> > > > > +{
> > > > > + struct aer_rpc *rpc = get_service_data(dev);
> > > > > +
> > > > > + aer_enable_rootport(rpc);
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > /**
> > > > > * aer_root_reset - reset Root Port hierarchy, RCEC, or RCiEP
> > > > > * @dev: pointer to Root Port, RCEC, or RCiEP
> > > > > @@ -1437,6 +1453,8 @@ static struct pcie_port_service_driver aerdriver = {
> > > > > .service = PCIE_PORT_SERVICE_AER,
> > > > >
> > > > > .probe = aer_probe,
> > > > > + .suspend = aer_suspend,
> > > > > + .resume = aer_resume,
> > > > > .remove = aer_remove,
> > > > > };
> > > > >
> > > > > --
> > > > > 2.29.2
> > > > >
^ permalink raw reply
* Re: [PATCH 1/2] PCI/AER: Disable AER interrupt during suspend
From: Christoph Hellwig @ 2021-07-23 5:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Joerg Roedel, Mika Westerberg, open list:PCI SUBSYSTEM, open list,
Lalithambika Krishnakumar, Alex Williamson, Kai-Heng Feng,
Oliver O'Halloran, Bjorn Helgaas,
open list:PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC, Lu Baolu
In-Reply-To: <20210722222351.GA354095@bjorn-Precision-5520>
On Thu, Jul 22, 2021 at 05:23:51PM -0500, Bjorn Helgaas wrote:
> Marking both of these as "not applicable" for now because I don't
> think we really understand what's going on.
>
> Apparently a DMA occurs during suspend or resume and triggers an ACS
> violation. I don't think think such a DMA should occur in the first
> place.
>
> Or maybe, since you say the problem happens right after ACS is enabled
> during resume, we're doing the ACS enable incorrectly? Although I
> would think we should not be doing DMA at the same time we're enabling
> ACS, either.
>
> If this really is a system firmware issue, both HP and Dell should
> have the knowledge and equipment to figure out what's going on.
DMA on resume sounds really odd. OTOH the below mentioned case of
a DMA during suspend seems very like in some setup. NVMe has the
concept of a host memory buffer (HMB) that allows the PCIe device
to use arbitrary host memory for internal purposes. Combine this
with the "Storage D3" misfeature in modern x86 platforms that force
a slot into d3cold without consulting the driver first and you'd see
symptoms like this. Another case would be the NVMe equivalent of the
AER which could lead to a completion without host activity.
We now have quirks in the ACPI layer and NVMe to fully shut down the
NVMe controllers on these messed up systems with the "Storage D3"
misfeature which should avoid such "spurious" DMAs at the cost of
wearning out the device much faster.
^ permalink raw reply
* Re: [PATCH v5 10/11] powerpc/pseries/iommu: Make use of DDW for indirect mapping
From: Alexey Kardashevskiy @ 2021-07-23 5:34 UTC (permalink / raw)
To: Frederic Barrat, Leonardo Bras, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, David Gibson,
kernel test robot, Nicolin Chen
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <994051df-73b3-4dad-76aa-1a03d9afaf6d@linux.ibm.com>
On 22/07/2021 01:04, Frederic Barrat wrote:
>
>
> On 21/07/2021 05:32, Alexey Kardashevskiy wrote:
>>>> + struct iommu_table *newtbl;
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < ARRAY_SIZE(pci->phb->mem_resources); i++) {
>>>> + const unsigned long mask = IORESOURCE_MEM_64 |
>>>> IORESOURCE_MEM;
>>>> +
>>>> + /* Look for MMIO32 */
>>>> + if ((pci->phb->mem_resources[i].flags & mask) ==
>>>> IORESOURCE_MEM)
>>>> + break;
>>>> + }
>>>> +
>>>> + if (i == ARRAY_SIZE(pci->phb->mem_resources))
>>>> + goto out_del_list;
>>>
>>>
>>> So we exit and do nothing if there's no MMIO32 bar?
>>> Isn't the intent just to figure out the MMIO32 area to reserve it
>>> when init'ing the table? In which case we could default to 0,0
>>>
>>> I'm actually not clear why we are reserving this area on pseries.
>>
>>
>>
>> If we do not reserve it, then the iommu code will allocate DMA pages
>> from there and these addresses are MMIO32 from the kernel pov at
>> least. I saw crashes when (I think) a device tried DMAing to the top
>> 2GB of the bus space which happened to be a some other device's BAR.
>
>
> hmmm... then figuring out the correct range needs more work. We could
> have more than one MMIO32 bar. And they don't have to be adjacent.
They all have to be within the MMIO32 window of a PHB and we reserve the
entire window here.
> I
> don't see that we are reserving any range on the initial table though
> (on pseries).
True, we did not need to, as the hypervisor always took care of DMA and
MMIO32 regions to not overlap.
And in this series we do not (strictly speaking) need this either as
phyp never allocates more than one window dynamically and that only
window is always the second one starting from 0x800.0000.0000.0000. It
is probably my mistake that KVM allows a new window to start from 0 -
PAPR did not prohibit this explicitly.
And for the KVM case, we do not need to remove the default window as KVM
can pretty much always allocate as many TCE as the VM wants. But we
still allow removing the default window and creating a huge one instead
at 0x0 as this way we can allow 1:1 for every single PCI device even if
it only allows 48 (or similar but less than 64bit) DMA. Hope this makes
sense. Thanks,
--
Alexey
^ permalink raw reply
* [PATCH v7 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
From: Pratik R. Sampat @ 2021-07-23 5:46 UTC (permalink / raw)
To: mpe, benh, paulus, farosas, kjain, linuxppc-dev, kvm-ppc,
linux-kernel, psampat, pratik.r.sampat
In-Reply-To: <20210723054609.15033-1-psampat@linux.ibm.com>
Adds a generic interface to represent the energy and frequency related
PAPR attributes on the system using the new H_CALL
"H_GET_ENERGY_SCALE_INFO".
H_GET_EM_PARMS H_CALL was previously responsible for exporting this
information in the lparcfg, however the H_GET_EM_PARMS H_CALL
will be deprecated P10 onwards.
The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format:
hcall(
uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
uint64 flags, // Per the flag request
uint64 firstAttributeId,// The attribute id
uint64 bufferAddress, // Guest physical address of the output buffer
uint64 bufferSize // The size in bytes of the output buffer
);
This H_CALL can query either all the attributes at once with
firstAttributeId = 0, flags = 0 as well as query only one attribute
at a time with firstAttributeId = id, flags = 1.
The output buffer consists of the following
1. number of attributes - 8 bytes
2. array offset to the data location - 8 bytes
3. version info - 1 byte
4. A data array of size num attributes, which contains the following:
a. attribute ID - 8 bytes
b. attribute value in number - 8 bytes
c. attribute name in string - 64 bytes
d. attribute value in string - 64 bytes
The new H_CALL exports information in direct string value format, hence
a new interface has been introduced in
/sys/firmware/papr/energy_scale_info to export this information to
userspace in an extensible pass-through format.
The H_CALL returns the name, numeric value and string value (if exists)
The format of exposing the sysfs information is as follows:
/sys/firmware/papr/energy_scale_info/
|-- <id>/
|-- desc
|-- value
|-- value_desc (if exists)
|-- <id>/
|-- desc
|-- value
|-- value_desc (if exists)
...
The energy information that is exported is useful for userspace tools
such as powerpc-utils. Currently these tools infer the
"power_mode_data" value in the lparcfg, which in turn is obtained from
the to be deprecated H_GET_EM_PARMS H_CALL.
On future platforms, such userspace utilities will have to look at the
data returned from the new H_CALL being populated in this new sysfs
interface and report this information directly without the need of
interpretation.
Signed-off-by: Pratik R. Sampat <psampat@linux.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
.../sysfs-firmware-papr-energy-scale-info | 26 ++
arch/powerpc/include/asm/hvcall.h | 24 +-
arch/powerpc/kvm/trace_hv.h | 1 +
arch/powerpc/platforms/pseries/Makefile | 3 +-
.../pseries/papr_platform_attributes.c | 312 ++++++++++++++++++
5 files changed, 364 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c
diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
new file mode 100644
index 000000000000..139a576c7c9d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
@@ -0,0 +1,26 @@
+What: /sys/firmware/papr/energy_scale_info
+Date: June 2021
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Directory hosting a set of platform attributes like
+ energy/frequency on Linux running as a PAPR guest.
+
+ Each file in a directory contains a platform
+ attribute hierarchy pertaining to performance/
+ energy-savings mode and processor frequency.
+
+What: /sys/firmware/papr/energy_scale_info/<id>
+ /sys/firmware/papr/energy_scale_info/<id>/desc
+ /sys/firmware/papr/energy_scale_info/<id>/value
+ /sys/firmware/papr/energy_scale_info/<id>/value_desc
+Date: June 2021
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: Energy, frequency attributes directory for POWERVM servers
+
+ This directory provides energy, frequency, folding information. It
+ contains below sysfs attributes:
+
+ - desc: String description of the attribute <id>
+
+ - value: Numeric value of attribute <id>
+
+ - value_desc: String value of attribute <id>
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index e3b29eda8074..c91714ea6719 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -316,7 +316,8 @@
#define H_SCM_PERFORMANCE_STATS 0x418
#define H_RPT_INVALIDATE 0x448
#define H_SCM_FLUSH 0x44C
-#define MAX_HCALL_OPCODE H_SCM_FLUSH
+#define H_GET_ENERGY_SCALE_INFO 0x450
+#define MAX_HCALL_OPCODE H_GET_ENERGY_SCALE_INFO
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
@@ -631,6 +632,27 @@ struct hv_gpci_request_buffer {
uint8_t bytes[HGPCI_MAX_DATA_BYTES];
} __packed;
+#define ESI_VERSION 0x1
+#define MAX_ESI_ATTRS 10
+#define MAX_BUF_SZ (sizeof(struct h_energy_scale_info_hdr) + \
+ (sizeof(struct energy_scale_attribute) * MAX_ESI_ATTRS))
+
+struct energy_scale_attribute {
+ __be64 id;
+ __be64 value;
+ unsigned char desc[64];
+ unsigned char value_desc[64];
+} __packed;
+
+struct h_energy_scale_info_hdr {
+ __be64 num_attrs;
+ __be64 array_offset;
+ __u8 data_header_version;
+} __packed;
+
+/* /sys/firmware/papr */
+extern struct kobject *papr_kobj;
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
diff --git a/arch/powerpc/kvm/trace_hv.h b/arch/powerpc/kvm/trace_hv.h
index 830a126e095d..38cd0ed0a617 100644
--- a/arch/powerpc/kvm/trace_hv.h
+++ b/arch/powerpc/kvm/trace_hv.h
@@ -115,6 +115,7 @@
{H_VASI_STATE, "H_VASI_STATE"}, \
{H_ENABLE_CRQ, "H_ENABLE_CRQ"}, \
{H_GET_EM_PARMS, "H_GET_EM_PARMS"}, \
+ {H_GET_ENERGY_SCALE_INFO, "H_GET_ENERGY_SCALE_INFO"}, \
{H_SET_MPP, "H_SET_MPP"}, \
{H_GET_MPP, "H_GET_MPP"}, \
{H_HOME_NODE_ASSOCIATIVITY, "H_HOME_NODE_ASSOCIATIVITY"}, \
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index c8a2b0b05ac0..d14fca89ac25 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -6,7 +6,8 @@ obj-y := lpar.o hvCall.o nvram.o reconfig.o \
of_helpers.o \
setup.o iommu.o event_sources.o ras.o \
firmware.o power.o dlpar.o mobility.o rng.o \
- pci.o pci_dlpar.o eeh_pseries.o msi.o
+ pci.o pci_dlpar.o eeh_pseries.o msi.o \
+ papr_platform_attributes.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SCANLOG) += scanlog.o
obj-$(CONFIG_KEXEC_CORE) += kexec.o
diff --git a/arch/powerpc/platforms/pseries/papr_platform_attributes.c b/arch/powerpc/platforms/pseries/papr_platform_attributes.c
new file mode 100644
index 000000000000..84ddce52e519
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/papr_platform_attributes.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Platform energy and frequency attributes driver
+ *
+ * This driver creates a sys file at /sys/firmware/papr/ which encapsulates a
+ * directory structure containing files in keyword - value pairs that specify
+ * energy and frequency configuration of the system.
+ *
+ * The format of exposing the sysfs information is as follows:
+ * /sys/firmware/papr/energy_scale_info/
+ * |-- <id>/
+ * |-- desc
+ * |-- value
+ * |-- value_desc (if exists)
+ * |-- <id>/
+ * |-- desc
+ * |-- value
+ * |-- value_desc (if exists)
+ *
+ * Copyright 2021 IBM Corp.
+ */
+
+#include <asm/hvcall.h>
+#include <asm/machdep.h>
+
+#include "pseries.h"
+
+/*
+ * Flag attributes to fetch either all or one attribute from the HCALL
+ * flag = BE(0) => fetch all attributes with firstAttributeId = 0
+ * flag = BE(1) => fetch a single attribute with firstAttributeId = id
+ */
+#define ESI_FLAGS_ALL 0
+#define ESI_FLAGS_SINGLE PPC_BIT(0)
+
+#define MAX_ATTRS 3
+
+struct papr_attr {
+ u64 id;
+ struct kobj_attribute kobj_attr;
+};
+struct papr_group {
+ struct attribute_group pg;
+ struct papr_attr pgattrs[MAX_ATTRS];
+} *pgs;
+
+/* /sys/firmware/papr */
+struct kobject *papr_kobj;
+/* /sys/firmware/papr/energy_scale_info */
+struct kobject *esi_kobj;
+
+/*
+ * Extract and export the description of the energy scale attributes
+ */
+static ssize_t papr_show_desc(struct kobject *kobj,
+ struct kobj_attribute *kobj_attr,
+ char *buf)
+{
+ struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
+ kobj_attr);
+ struct h_energy_scale_info_hdr *t_hdr;
+ struct energy_scale_attribute *t_esi;
+ char *t_buf;
+ int ret = 0;
+
+ t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
+ if (t_buf == NULL)
+ return -ENOMEM;
+
+ ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
+ pattr->id, virt_to_phys(t_buf),
+ MAX_BUF_SZ);
+
+ if (ret != H_SUCCESS) {
+ pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
+ goto out;
+ }
+
+ t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
+ t_esi = (struct energy_scale_attribute *)
+ (t_buf + be64_to_cpu(t_hdr->array_offset));
+
+ ret = snprintf(buf, sizeof(t_esi->desc), "%s\n", t_esi->desc);
+ if (ret < 0)
+ ret = -EIO;
+out:
+ kfree(t_buf);
+
+ return ret;
+}
+
+/*
+ * Extract and export the numeric value of the energy scale attributes
+ */
+static ssize_t papr_show_value(struct kobject *kobj,
+ struct kobj_attribute *kobj_attr,
+ char *buf)
+{
+ struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
+ kobj_attr);
+ struct h_energy_scale_info_hdr *t_hdr;
+ struct energy_scale_attribute *t_esi;
+ char *t_buf;
+ int ret = 0;
+
+ t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
+ if (t_buf == NULL)
+ return -ENOMEM;
+
+ ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
+ pattr->id, virt_to_phys(t_buf),
+ MAX_BUF_SZ);
+
+ if (ret != H_SUCCESS) {
+ pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
+ goto out;
+ }
+
+ t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
+ t_esi = (struct energy_scale_attribute *)
+ (t_buf + be64_to_cpu(t_hdr->array_offset));
+
+ ret = snprintf(buf, sizeof(t_esi->value), "%llu\n",
+ be64_to_cpu(t_esi->value));
+ if (ret < 0)
+ ret = -EIO;
+out:
+ kfree(t_buf);
+
+ return ret;
+}
+
+/*
+ * Extract and export the value description in string format of the energy
+ * scale attributes
+ */
+static ssize_t papr_show_value_desc(struct kobject *kobj,
+ struct kobj_attribute *kobj_attr,
+ char *buf)
+{
+ struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
+ kobj_attr);
+ struct h_energy_scale_info_hdr *t_hdr;
+ struct energy_scale_attribute *t_esi;
+ char *t_buf;
+ int ret = 0;
+
+ t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
+ if (t_buf == NULL)
+ return -ENOMEM;
+
+ ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
+ pattr->id, virt_to_phys(t_buf),
+ MAX_BUF_SZ);
+
+ if (ret != H_SUCCESS) {
+ pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
+ goto out;
+ }
+
+ t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
+ t_esi = (struct energy_scale_attribute *)
+ (t_buf + be64_to_cpu(t_hdr->array_offset));
+
+ ret = snprintf(buf, sizeof(t_esi->value_desc), "%s\n",
+ t_esi->value_desc);
+ if (ret < 0)
+ ret = -EIO;
+out:
+ kfree(t_buf);
+
+ return ret;
+}
+
+static struct papr_ops_info {
+ const char *attr_name;
+ ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *kobj_attr,
+ char *buf);
+} ops_info[MAX_ATTRS] = {
+ { "desc", papr_show_desc },
+ { "value", papr_show_value },
+ { "value_desc", papr_show_value_desc },
+};
+
+static void add_attr(u64 id, int index, struct papr_attr *attr)
+{
+ attr->id = id;
+ sysfs_attr_init(&attr->kobj_attr.attr);
+ attr->kobj_attr.attr.name = ops_info[index].attr_name;
+ attr->kobj_attr.attr.mode = 0444;
+ attr->kobj_attr.show = ops_info[index].show;
+}
+
+static int add_attr_group(u64 id, struct papr_group *pg, bool show_val_desc)
+{
+ int i;
+
+ for (i = 0; i < MAX_ATTRS; i++) {
+ if (!strcmp(ops_info[i].attr_name, "value_desc") &&
+ !show_val_desc) {
+ continue;
+ }
+ add_attr(id, i, &pg->pgattrs[i]);
+ pg->pg.attrs[i] = &pg->pgattrs[i].kobj_attr.attr;
+ }
+
+ return sysfs_create_group(esi_kobj, &pg->pg);
+}
+
+static int __init papr_init(void)
+{
+ struct h_energy_scale_info_hdr *esi_hdr;
+ struct energy_scale_attribute *esi_attrs;
+ uint64_t num_attrs;
+ int ret, idx, i;
+ char *esi_buf;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return -ENXIO;
+
+ esi_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
+ if (esi_buf == NULL)
+ return -ENOMEM;
+ /*
+ * hcall(
+ * uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
+ * uint64 flags, // Per the flag request
+ * uint64 firstAttributeId, // The attribute id
+ * uint64 bufferAddress, // Guest physical address of the output buffer
+ * uint64 bufferSize); // The size in bytes of the output buffer
+ */
+ ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_ALL, 0,
+ virt_to_phys(esi_buf), MAX_BUF_SZ);
+ if (ret != H_SUCCESS) {
+ pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
+ goto out;
+ }
+
+ esi_hdr = (struct h_energy_scale_info_hdr *) esi_buf;
+ if (esi_hdr->data_header_version != ESI_VERSION) {
+ pr_warn("H_GET_ENERGY_SCALE_INFO VER MISMATCH - EXP: 0x%x, REC: 0x%x",
+ ESI_VERSION, esi_hdr->data_header_version);
+ }
+
+ num_attrs = be64_to_cpu(esi_hdr->num_attrs);
+ esi_attrs = (struct energy_scale_attribute *)
+ (esi_buf + be64_to_cpu(esi_hdr->array_offset));
+
+ pgs = kcalloc(num_attrs, sizeof(*pgs), GFP_KERNEL);
+ if (!pgs)
+ goto out;
+
+ papr_kobj = kobject_create_and_add("papr", firmware_kobj);
+ if (!papr_kobj) {
+ pr_warn("kobject_create_and_add papr failed\n");
+ goto out_pgs;
+ }
+
+ esi_kobj = kobject_create_and_add("energy_scale_info", papr_kobj);
+ if (!esi_kobj) {
+ pr_warn("kobject_create_and_add energy_scale_info failed\n");
+ goto out_kobj;
+ }
+
+ for (idx = 0; idx < num_attrs; idx++) {
+ bool show_val_desc = true;
+
+ pgs[idx].pg.attrs = kcalloc(MAX_ATTRS + 1,
+ sizeof(*pgs[idx].pg.attrs),
+ GFP_KERNEL);
+ if (!pgs[idx].pg.attrs) {
+ goto out_pgattrs;
+ }
+
+ pgs[idx].pg.name = kasprintf(GFP_KERNEL, "%lld",
+ be64_to_cpu(esi_attrs[idx].id));
+ if (pgs[idx].pg.name == NULL) {
+ goto out_pgattrs;
+ }
+ /* Do not add the value description if it does not exist */
+ if (strnlen(esi_attrs[idx].value_desc,
+ sizeof(esi_attrs[idx].value_desc)) == 0)
+ show_val_desc = false;
+
+ if (add_attr_group(be64_to_cpu(esi_attrs[idx].id), &pgs[idx],
+ show_val_desc)) {
+ pr_warn("Failed to create papr attribute group %s\n",
+ pgs[idx].pg.name);
+ goto out_pgattrs;
+ }
+ }
+
+ kfree(esi_buf);
+ return 0;
+
+out_pgattrs:
+ for (i = 0; i < idx ; i++) {
+ kfree(pgs[i].pg.attrs);
+ kfree(pgs[i].pg.name);
+ }
+ kobject_put(esi_kobj);
+out_kobj:
+ kobject_put(papr_kobj);
+out_pgs:
+ kfree(pgs);
+out:
+ kfree(esi_buf);
+
+ return -ENOMEM;
+}
+
+machine_device_initcall(pseries, papr_init);
--
2.31.1
^ permalink raw reply related
* [PATCH v7 0/1] Interface to represent PAPR firmware attributes
From: Pratik R. Sampat @ 2021-07-23 5:46 UTC (permalink / raw)
To: mpe, benh, paulus, farosas, kjain, linuxppc-dev, kvm-ppc,
linux-kernel, psampat, pratik.r.sampat
RFC: https://lkml.org/lkml/2021/6/4/791
PATCH v1: https://lkml.org/lkml/2021/6/16/805
PATCH v2: https://lkml.org/lkml/2021/7/6/138
PATCH v3: https://lkml.org/lkml/2021/7/12/2799
PATCH v4: https://lkml.org/lkml/2021/7/16/532
PATCH v5: https://lkml.org/lkml/2021/7/19/247
PATCH v6: https://lkml.org/lkml/2021/7/20/36
Changelog v6-->v7
1. Optimize free for pgs attributes to iterate only over the currently
allocated attributes "idx" instead of free'ing for all
Also, have implemented a POC using this interface for the powerpc-utils'
ppc64_cpu --frequency command-line tool to utilize this information
in userspace.
The POC for the new interface has been hosted here:
https://github.com/pratiksampat/powerpc-utils/tree/H_GET_ENERGY_SCALE_INFO_v2
Sample output from the powerpc-utils tool is as follows:
# ppc64_cpu --frequency
Power and Performance Mode: XXXX
Idle Power Saver Status : XXXX
Processor Folding Status : XXXX --> Printed if Idle power save status is supported
Platform reported frequencies --> Frequencies reported from the platform's H_CALL i.e PAPR interface
min : NNNN GHz
max : NNNN GHz
static : NNNN GHz
Tool Computed frequencies
min : NNNN GHz (cpu XX)
max : NNNN GHz (cpu XX)
avg : NNNN GHz
Pratik R. Sampat (1):
powerpc/pseries: Interface to represent PAPR firmware attributes
.../sysfs-firmware-papr-energy-scale-info | 26 ++
arch/powerpc/include/asm/hvcall.h | 24 +-
arch/powerpc/kvm/trace_hv.h | 1 +
arch/powerpc/platforms/pseries/Makefile | 3 +-
.../pseries/papr_platform_attributes.c | 312 ++++++++++++++++++
5 files changed, 364 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c
--
2.31.1
^ permalink raw reply
* Re: [PATCH v7 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
From: kajoljain @ 2021-07-23 6:10 UTC (permalink / raw)
To: Pratik R. Sampat, mpe, benh, paulus, farosas, linuxppc-dev,
kvm-ppc, linux-kernel, pratik.r.sampat
In-Reply-To: <20210723054609.15033-2-psampat@linux.ibm.com>
On 7/23/21 11:16 AM, Pratik R. Sampat wrote:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERGY_SCALE_INFO".
>
> H_GET_EM_PARMS H_CALL was previously responsible for exporting this
> information in the lparcfg, however the H_GET_EM_PARMS H_CALL
> will be deprecated P10 onwards.
>
> The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format:
> hcall(
> uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
> uint64 flags, // Per the flag request
> uint64 firstAttributeId,// The attribute id
> uint64 bufferAddress, // Guest physical address of the output buffer
> uint64 bufferSize // The size in bytes of the output buffer
> );
>
> This H_CALL can query either all the attributes at once with
> firstAttributeId = 0, flags = 0 as well as query only one attribute
> at a time with firstAttributeId = id, flags = 1.
>
> The output buffer consists of the following
> 1. number of attributes - 8 bytes
> 2. array offset to the data location - 8 bytes
> 3. version info - 1 byte
> 4. A data array of size num attributes, which contains the following:
> a. attribute ID - 8 bytes
> b. attribute value in number - 8 bytes
> c. attribute name in string - 64 bytes
> d. attribute value in string - 64 bytes
>
> The new H_CALL exports information in direct string value format, hence
> a new interface has been introduced in
> /sys/firmware/papr/energy_scale_info to export this information to
> userspace in an extensible pass-through format.
>
> The H_CALL returns the name, numeric value and string value (if exists)
>
> The format of exposing the sysfs information is as follows:
> /sys/firmware/papr/energy_scale_info/
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc (if exists)
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc (if exists)
> ...
>
> The energy information that is exported is useful for userspace tools
> such as powerpc-utils. Currently these tools infer the
> "power_mode_data" value in the lparcfg, which in turn is obtained from
> the to be deprecated H_GET_EM_PARMS H_CALL.
> On future platforms, such userspace utilities will have to look at the
> data returned from the new H_CALL being populated in this new sysfs
> interface and report this information directly without the need of
> interpretation.
>
Patch looks good to me.
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol Jain
> Signed-off-by: Pratik R. Sampat <psampat@linux.ibm.com>
> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> .../sysfs-firmware-papr-energy-scale-info | 26 ++
> arch/powerpc/include/asm/hvcall.h | 24 +-
> arch/powerpc/kvm/trace_hv.h | 1 +
> arch/powerpc/platforms/pseries/Makefile | 3 +-
> .../pseries/papr_platform_attributes.c | 312 ++++++++++++++++++
> 5 files changed, 364 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
> create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
> new file mode 100644
> index 000000000000..139a576c7c9d
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
> @@ -0,0 +1,26 @@
> +What: /sys/firmware/papr/energy_scale_info
> +Date: June 2021
> +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
> +Description: Directory hosting a set of platform attributes like
> + energy/frequency on Linux running as a PAPR guest.
> +
> + Each file in a directory contains a platform
> + attribute hierarchy pertaining to performance/
> + energy-savings mode and processor frequency.
> +
> +What: /sys/firmware/papr/energy_scale_info/<id>
> + /sys/firmware/papr/energy_scale_info/<id>/desc
> + /sys/firmware/papr/energy_scale_info/<id>/value
> + /sys/firmware/papr/energy_scale_info/<id>/value_desc
> +Date: June 2021
> +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
> +Description: Energy, frequency attributes directory for POWERVM servers
> +
> + This directory provides energy, frequency, folding information. It
> + contains below sysfs attributes:
> +
> + - desc: String description of the attribute <id>
> +
> + - value: Numeric value of attribute <id>
> +
> + - value_desc: String value of attribute <id>
> diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
> index e3b29eda8074..c91714ea6719 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -316,7 +316,8 @@
> #define H_SCM_PERFORMANCE_STATS 0x418
> #define H_RPT_INVALIDATE 0x448
> #define H_SCM_FLUSH 0x44C
> -#define MAX_HCALL_OPCODE H_SCM_FLUSH
> +#define H_GET_ENERGY_SCALE_INFO 0x450
> +#define MAX_HCALL_OPCODE H_GET_ENERGY_SCALE_INFO
>
> /* Scope args for H_SCM_UNBIND_ALL */
> #define H_UNBIND_SCOPE_ALL (0x1)
> @@ -631,6 +632,27 @@ struct hv_gpci_request_buffer {
> uint8_t bytes[HGPCI_MAX_DATA_BYTES];
> } __packed;
>
> +#define ESI_VERSION 0x1
> +#define MAX_ESI_ATTRS 10
> +#define MAX_BUF_SZ (sizeof(struct h_energy_scale_info_hdr) + \
> + (sizeof(struct energy_scale_attribute) * MAX_ESI_ATTRS))
> +
> +struct energy_scale_attribute {
> + __be64 id;
> + __be64 value;
> + unsigned char desc[64];
> + unsigned char value_desc[64];
> +} __packed;
> +
> +struct h_energy_scale_info_hdr {
> + __be64 num_attrs;
> + __be64 array_offset;
> + __u8 data_header_version;
> +} __packed;
> +
> +/* /sys/firmware/papr */
> +extern struct kobject *papr_kobj;
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_HVCALL_H */
> diff --git a/arch/powerpc/kvm/trace_hv.h b/arch/powerpc/kvm/trace_hv.h
> index 830a126e095d..38cd0ed0a617 100644
> --- a/arch/powerpc/kvm/trace_hv.h
> +++ b/arch/powerpc/kvm/trace_hv.h
> @@ -115,6 +115,7 @@
> {H_VASI_STATE, "H_VASI_STATE"}, \
> {H_ENABLE_CRQ, "H_ENABLE_CRQ"}, \
> {H_GET_EM_PARMS, "H_GET_EM_PARMS"}, \
> + {H_GET_ENERGY_SCALE_INFO, "H_GET_ENERGY_SCALE_INFO"}, \
> {H_SET_MPP, "H_SET_MPP"}, \
> {H_GET_MPP, "H_GET_MPP"}, \
> {H_HOME_NODE_ASSOCIATIVITY, "H_HOME_NODE_ASSOCIATIVITY"}, \
> diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> index c8a2b0b05ac0..d14fca89ac25 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -6,7 +6,8 @@ obj-y := lpar.o hvCall.o nvram.o reconfig.o \
> of_helpers.o \
> setup.o iommu.o event_sources.o ras.o \
> firmware.o power.o dlpar.o mobility.o rng.o \
> - pci.o pci_dlpar.o eeh_pseries.o msi.o
> + pci.o pci_dlpar.o eeh_pseries.o msi.o \
> + papr_platform_attributes.o
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_SCANLOG) += scanlog.o
> obj-$(CONFIG_KEXEC_CORE) += kexec.o
> diff --git a/arch/powerpc/platforms/pseries/papr_platform_attributes.c b/arch/powerpc/platforms/pseries/papr_platform_attributes.c
> new file mode 100644
> index 000000000000..84ddce52e519
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/papr_platform_attributes.c
> @@ -0,0 +1,312 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Platform energy and frequency attributes driver
> + *
> + * This driver creates a sys file at /sys/firmware/papr/ which encapsulates a
> + * directory structure containing files in keyword - value pairs that specify
> + * energy and frequency configuration of the system.
> + *
> + * The format of exposing the sysfs information is as follows:
> + * /sys/firmware/papr/energy_scale_info/
> + * |-- <id>/
> + * |-- desc
> + * |-- value
> + * |-- value_desc (if exists)
> + * |-- <id>/
> + * |-- desc
> + * |-- value
> + * |-- value_desc (if exists)
> + *
> + * Copyright 2021 IBM Corp.
> + */
> +
> +#include <asm/hvcall.h>
> +#include <asm/machdep.h>
> +
> +#include "pseries.h"
> +
> +/*
> + * Flag attributes to fetch either all or one attribute from the HCALL
> + * flag = BE(0) => fetch all attributes with firstAttributeId = 0
> + * flag = BE(1) => fetch a single attribute with firstAttributeId = id
> + */
> +#define ESI_FLAGS_ALL 0
> +#define ESI_FLAGS_SINGLE PPC_BIT(0)
> +
> +#define MAX_ATTRS 3
> +
> +struct papr_attr {
> + u64 id;
> + struct kobj_attribute kobj_attr;
> +};
> +struct papr_group {
> + struct attribute_group pg;
> + struct papr_attr pgattrs[MAX_ATTRS];
> +} *pgs;
> +
> +/* /sys/firmware/papr */
> +struct kobject *papr_kobj;
> +/* /sys/firmware/papr/energy_scale_info */
> +struct kobject *esi_kobj;
> +
> +/*
> + * Extract and export the description of the energy scale attributes
> + */
> +static ssize_t papr_show_desc(struct kobject *kobj,
> + struct kobj_attribute *kobj_attr,
> + char *buf)
> +{
> + struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
> + kobj_attr);
> + struct h_energy_scale_info_hdr *t_hdr;
> + struct energy_scale_attribute *t_esi;
> + char *t_buf;
> + int ret = 0;
> +
> + t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
> + if (t_buf == NULL)
> + return -ENOMEM;
> +
> + ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
> + pattr->id, virt_to_phys(t_buf),
> + MAX_BUF_SZ);
> +
> + if (ret != H_SUCCESS) {
> + pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
> + goto out;
> + }
> +
> + t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
> + t_esi = (struct energy_scale_attribute *)
> + (t_buf + be64_to_cpu(t_hdr->array_offset));
> +
> + ret = snprintf(buf, sizeof(t_esi->desc), "%s\n", t_esi->desc);
> + if (ret < 0)
> + ret = -EIO;
> +out:
> + kfree(t_buf);
> +
> + return ret;
> +}
> +
> +/*
> + * Extract and export the numeric value of the energy scale attributes
> + */
> +static ssize_t papr_show_value(struct kobject *kobj,
> + struct kobj_attribute *kobj_attr,
> + char *buf)
> +{
> + struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
> + kobj_attr);
> + struct h_energy_scale_info_hdr *t_hdr;
> + struct energy_scale_attribute *t_esi;
> + char *t_buf;
> + int ret = 0;
> +
> + t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
> + if (t_buf == NULL)
> + return -ENOMEM;
> +
> + ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
> + pattr->id, virt_to_phys(t_buf),
> + MAX_BUF_SZ);
> +
> + if (ret != H_SUCCESS) {
> + pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
> + goto out;
> + }
> +
> + t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
> + t_esi = (struct energy_scale_attribute *)
> + (t_buf + be64_to_cpu(t_hdr->array_offset));
> +
> + ret = snprintf(buf, sizeof(t_esi->value), "%llu\n",
> + be64_to_cpu(t_esi->value));
> + if (ret < 0)
> + ret = -EIO;
> +out:
> + kfree(t_buf);
> +
> + return ret;
> +}
> +
> +/*
> + * Extract and export the value description in string format of the energy
> + * scale attributes
> + */
> +static ssize_t papr_show_value_desc(struct kobject *kobj,
> + struct kobj_attribute *kobj_attr,
> + char *buf)
> +{
> + struct papr_attr *pattr = container_of(kobj_attr, struct papr_attr,
> + kobj_attr);
> + struct h_energy_scale_info_hdr *t_hdr;
> + struct energy_scale_attribute *t_esi;
> + char *t_buf;
> + int ret = 0;
> +
> + t_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
> + if (t_buf == NULL)
> + return -ENOMEM;
> +
> + ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_SINGLE,
> + pattr->id, virt_to_phys(t_buf),
> + MAX_BUF_SZ);
> +
> + if (ret != H_SUCCESS) {
> + pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
> + goto out;
> + }
> +
> + t_hdr = (struct h_energy_scale_info_hdr *) t_buf;
> + t_esi = (struct energy_scale_attribute *)
> + (t_buf + be64_to_cpu(t_hdr->array_offset));
> +
> + ret = snprintf(buf, sizeof(t_esi->value_desc), "%s\n",
> + t_esi->value_desc);
> + if (ret < 0)
> + ret = -EIO;
> +out:
> + kfree(t_buf);
> +
> + return ret;
> +}
> +
> +static struct papr_ops_info {
> + const char *attr_name;
> + ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *kobj_attr,
> + char *buf);
> +} ops_info[MAX_ATTRS] = {
> + { "desc", papr_show_desc },
> + { "value", papr_show_value },
> + { "value_desc", papr_show_value_desc },
> +};
> +
> +static void add_attr(u64 id, int index, struct papr_attr *attr)
> +{
> + attr->id = id;
> + sysfs_attr_init(&attr->kobj_attr.attr);
> + attr->kobj_attr.attr.name = ops_info[index].attr_name;
> + attr->kobj_attr.attr.mode = 0444;
> + attr->kobj_attr.show = ops_info[index].show;
> +}
> +
> +static int add_attr_group(u64 id, struct papr_group *pg, bool show_val_desc)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_ATTRS; i++) {
> + if (!strcmp(ops_info[i].attr_name, "value_desc") &&
> + !show_val_desc) {
> + continue;
> + }
> + add_attr(id, i, &pg->pgattrs[i]);
> + pg->pg.attrs[i] = &pg->pgattrs[i].kobj_attr.attr;
> + }
> +
> + return sysfs_create_group(esi_kobj, &pg->pg);
> +}
> +
> +static int __init papr_init(void)
> +{
> + struct h_energy_scale_info_hdr *esi_hdr;
> + struct energy_scale_attribute *esi_attrs;
> + uint64_t num_attrs;
> + int ret, idx, i;
> + char *esi_buf;
> +
> + if (!firmware_has_feature(FW_FEATURE_LPAR))
> + return -ENXIO;
> +
> + esi_buf = kmalloc(MAX_BUF_SZ, GFP_KERNEL);
> + if (esi_buf == NULL)
> + return -ENOMEM;
> + /*
> + * hcall(
> + * uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
> + * uint64 flags, // Per the flag request
> + * uint64 firstAttributeId, // The attribute id
> + * uint64 bufferAddress, // Guest physical address of the output buffer
> + * uint64 bufferSize); // The size in bytes of the output buffer
> + */
> + ret = plpar_hcall_norets(H_GET_ENERGY_SCALE_INFO, ESI_FLAGS_ALL, 0,
> + virt_to_phys(esi_buf), MAX_BUF_SZ);
> + if (ret != H_SUCCESS) {
> + pr_warn("hcall failed: H_GET_ENERGY_SCALE_INFO");
> + goto out;
> + }
> +
> + esi_hdr = (struct h_energy_scale_info_hdr *) esi_buf;
> + if (esi_hdr->data_header_version != ESI_VERSION) {
> + pr_warn("H_GET_ENERGY_SCALE_INFO VER MISMATCH - EXP: 0x%x, REC: 0x%x",
> + ESI_VERSION, esi_hdr->data_header_version);
> + }
> +
> + num_attrs = be64_to_cpu(esi_hdr->num_attrs);
> + esi_attrs = (struct energy_scale_attribute *)
> + (esi_buf + be64_to_cpu(esi_hdr->array_offset));
> +
> + pgs = kcalloc(num_attrs, sizeof(*pgs), GFP_KERNEL);
> + if (!pgs)
> + goto out;
> +
> + papr_kobj = kobject_create_and_add("papr", firmware_kobj);
> + if (!papr_kobj) {
> + pr_warn("kobject_create_and_add papr failed\n");
> + goto out_pgs;
> + }
> +
> + esi_kobj = kobject_create_and_add("energy_scale_info", papr_kobj);
> + if (!esi_kobj) {
> + pr_warn("kobject_create_and_add energy_scale_info failed\n");
> + goto out_kobj;
> + }
> +
> + for (idx = 0; idx < num_attrs; idx++) {
> + bool show_val_desc = true;
> +
> + pgs[idx].pg.attrs = kcalloc(MAX_ATTRS + 1,
> + sizeof(*pgs[idx].pg.attrs),
> + GFP_KERNEL);
> + if (!pgs[idx].pg.attrs) {
> + goto out_pgattrs;
> + }
> +
> + pgs[idx].pg.name = kasprintf(GFP_KERNEL, "%lld",
> + be64_to_cpu(esi_attrs[idx].id));
> + if (pgs[idx].pg.name == NULL) {
> + goto out_pgattrs;
> + }
> + /* Do not add the value description if it does not exist */
> + if (strnlen(esi_attrs[idx].value_desc,
> + sizeof(esi_attrs[idx].value_desc)) == 0)
> + show_val_desc = false;
> +
> + if (add_attr_group(be64_to_cpu(esi_attrs[idx].id), &pgs[idx],
> + show_val_desc)) {
> + pr_warn("Failed to create papr attribute group %s\n",
> + pgs[idx].pg.name);
> + goto out_pgattrs;
> + }
> + }
> +
> + kfree(esi_buf);
> + return 0;
> +
> +out_pgattrs:
> + for (i = 0; i < idx ; i++) {
> + kfree(pgs[i].pg.attrs);
> + kfree(pgs[i].pg.name);
> + }
> + kobject_put(esi_kobj);
> +out_kobj:
> + kobject_put(papr_kobj);
> +out_pgs:
> + kfree(pgs);
> +out:
> + kfree(esi_buf);
> +
> + return -ENOMEM;
> +}
> +
> +machine_device_initcall(pseries, papr_init);
>
^ permalink raw reply
* Re: [PATCH 1/2] PCI/AER: Disable AER interrupt during suspend
From: Kai-Heng Feng @ 2021-07-23 7:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Joerg Roedel, Mika Westerberg, open list:PCI SUBSYSTEM, open list,
Lalithambika Krishnakumar, Alex Williamson, Bjorn Helgaas,
Bjorn Helgaas, Oliver O'Halloran,
open list:PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC, Lu Baolu
In-Reply-To: <YPpShrTa448OpGjA@infradead.org>
On Fri, Jul 23, 2021 at 1:24 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Jul 22, 2021 at 05:23:51PM -0500, Bjorn Helgaas wrote:
> > Marking both of these as "not applicable" for now because I don't
> > think we really understand what's going on.
> >
> > Apparently a DMA occurs during suspend or resume and triggers an ACS
> > violation. I don't think think such a DMA should occur in the first
> > place.
> >
> > Or maybe, since you say the problem happens right after ACS is enabled
> > during resume, we're doing the ACS enable incorrectly? Although I
> > would think we should not be doing DMA at the same time we're enabling
> > ACS, either.
> >
> > If this really is a system firmware issue, both HP and Dell should
> > have the knowledge and equipment to figure out what's going on.
>
> DMA on resume sounds really odd. OTOH the below mentioned case of
> a DMA during suspend seems very like in some setup. NVMe has the
> concept of a host memory buffer (HMB) that allows the PCIe device
> to use arbitrary host memory for internal purposes. Combine this
> with the "Storage D3" misfeature in modern x86 platforms that force
> a slot into d3cold without consulting the driver first and you'd see
> symptoms like this. Another case would be the NVMe equivalent of the
> AER which could lead to a completion without host activity.
The issue can also be observed on non-HMB NVMe.
>
> We now have quirks in the ACPI layer and NVMe to fully shut down the
> NVMe controllers on these messed up systems with the "Storage D3"
> misfeature which should avoid such "spurious" DMAs at the cost of
> wearning out the device much faster.
Since the issue is on S3, I think the NVMe always fully shuts down.
Kai-Heng
^ permalink raw reply
* [PATCH 2/8] hvsi: don't panic on tty_register_driver failure
From: Jiri Slaby @ 2021-07-23 7:43 UTC (permalink / raw)
To: gregkh; +Cc: linuxppc-dev, Jiri Slaby, linux-kernel, linux-serial
In-Reply-To: <20210723074317.32690-1-jslaby@suse.cz>
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index bfc15279d5bc..f0bc8e780051 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.32.0
^ permalink raw reply related
* [Bug 205303] Compilation for PPC64 fails on warning in watchdog.o
From: bugzilla-daemon @ 2021-07-23 10:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205303-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205303
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |michael@ellerman.id.au
Resolution|--- |CODE_FIX
--- Comment #3 from Michael Ellerman (michael@ellerman.id.au) ---
This was fixed by:
4fe529449d85 ("powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration")
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v2] Revert "mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge"
From: Michael Ellerman @ 2021-07-23 12:04 UTC (permalink / raw)
To: Will Deacon, Christophe Leroy
Cc: Mark Rutland, Marc Zyngier, linux-kernel, Jonathan Marek,
Will Deacon, catalin.marinas, linuxppc-dev, Nicholas Piggin,
Ard Biesheuvel, Geert Uytterhoeven, linux-arm-kernel,
Paul Mackerras, Thomas Gleixner, kernel-team, Andrew Morton,
Mike Rapoport
In-Reply-To: <162686329170.980657.905966885675716231.b4-ty@kernel.org>
Will Deacon <will@kernel.org> writes:
> On Wed, 21 Jul 2021 17:02:13 +1000, Michael Ellerman wrote:
>> This reverts commit c742199a014de23ee92055c2473d91fe5561ffdf.
>>
>> c742199a014d ("mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge")
>> breaks arm64 in at least two ways for configurations where PUD or PMD
>> folding occur:
>>
>> 1. We no longer install huge-vmap mappings and silently fall back to
>> page-granular entries, despite being able to install block entries
>> at what is effectively the PGD level.
>>
>> [...]
>
> Thank you Michael! I owe you a beer next time I see you, if we don't go
> extinct before then.
No worries, thanks to Christophe for identifying the solution while on
vacation!
Beers seem a long way off, but hopefully one day :)
cheers
^ permalink raw reply
* [Bug 213079] [bisected] IRQ problems and crashes on a PowerMac G5 with 5.12.3
From: bugzilla-daemon @ 2021-07-23 12:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213079-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #15 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Oliver O'Halloran from comment #13)
> In the meanwhile, can you try the patch above? That seems to fix bug which
> is causing MSIs to be unusable. I'm not 100% sure why that woudld matter,
> but it's possible the crashes are due to some other bug which doesn't appear
> when MSIs are in use.
Now I had time to test your patch on top of kernel 5.13-rc6 and 5.13.4. Can't
test it on top of 5.14-rc2 due to bug #213803.
Your patch seems to work fine and I don't get this "irq 63: nobody cared"
messages and crashes any longer! However now when building stuff the G5 sooner
or later crashes with:
[...]
Kernel panic - not syncing: corrupted stack end detected inside scheduler
Call Trace:
CPU: 1 PID: 2968 Comm: powerpc64-unkno Tainted: G W
5.13.0-rc6-PowerMacG5+ #2
[c0000000717178c0] [c0000000005412d0] .dump_stack+0xe0/0x13c (unreliable)
[c000000071717960] [c0000000000681a0] .panic+0x168/0x430
[c000000071717a10] [c000000000809ca0] .__schedule+0x80/0x840
[c000000071717af0] [c0000000000a0ea8] .do_task_dead+0x54/0x58
[c000000071717b70] [c00000000006e7b4] .do_exit+0xa14/0xa6c
[c000000071717c60] [c00000000006e89c] .do_group_exit+0x50/0xb0
[c000000071717cf0] [c00000000006e910] .__wake_up_parent+0x0/0x34
[c000000071717d60] [c000000000021530] .system_call_exception+0x1b4/0x1ec
[c000000071717e10] [c00000000000b9c4] system_call_common+0xe4/0x214
--- interrupt: c00 at 0x3fffa8092aa8
NIP: 00003fffa8092aa8 LR: 00003fffa7ff2d04 CTR: 0000000000000000
REGS: c000000071717e80 TRAP: 0c00 Tainted: G W
(5.13.0-rc6-PowerMacG5+)
MSR: 900000000200f032 <SF,HV,VEC,EE,PR,FP,ME,IR,DR,RI> CR: 22000482 XER:
00000000
IRQMASK: 0
GPR00: 00000000000000ea 00003fffd04ef2a0 00003fffa81b1300 0000000000000000
GPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00003fffa8318c30 000000012e5ff800 00000001136b53b0
GPR16: 00000001200cec38 00003fffddea1c68 00000001200ceb28 000000000000002f
GPR20: 0000000000000000 00003fffa81abff8 0000000000000001 00003fffa81aaa58
GPR24: 0000000000000000 0000000000000000 0000000000000003 0000000000000001
GPR28: 0000000000000000 00003fffa8311c50 fffffffffffff000 0000000000000000
NIP [00003fffa8092aa8] 0x3fffa8092aa8
LR [00003fffa7ff2d04] 0x3fffa7ff2d04
--- interrupt: c00
Rebooting in 120 seconds..
Don't know whether this is related. I'll throw more debugging stuff in, file
this as a seperate issue and link it here just in case.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v7 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes
From: Fabiano Rosas @ 2021-07-23 13:16 UTC (permalink / raw)
To: Pratik R. Sampat, mpe, benh, paulus, kjain, linuxppc-dev, kvm-ppc,
linux-kernel, psampat, pratik.r.sampat
In-Reply-To: <20210723054609.15033-2-psampat@linux.ibm.com>
"Pratik R. Sampat" <psampat@linux.ibm.com> writes:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERGY_SCALE_INFO".
>
> H_GET_EM_PARMS H_CALL was previously responsible for exporting this
> information in the lparcfg, however the H_GET_EM_PARMS H_CALL
> will be deprecated P10 onwards.
>
> The H_GET_ENERGY_SCALE_INFO H_CALL is of the following call format:
> hcall(
> uint64 H_GET_ENERGY_SCALE_INFO, // Get energy scale info
> uint64 flags, // Per the flag request
> uint64 firstAttributeId,// The attribute id
> uint64 bufferAddress, // Guest physical address of the output buffer
> uint64 bufferSize // The size in bytes of the output buffer
> );
>
> This H_CALL can query either all the attributes at once with
> firstAttributeId = 0, flags = 0 as well as query only one attribute
> at a time with firstAttributeId = id, flags = 1.
>
> The output buffer consists of the following
> 1. number of attributes - 8 bytes
> 2. array offset to the data location - 8 bytes
> 3. version info - 1 byte
> 4. A data array of size num attributes, which contains the following:
> a. attribute ID - 8 bytes
> b. attribute value in number - 8 bytes
> c. attribute name in string - 64 bytes
> d. attribute value in string - 64 bytes
>
> The new H_CALL exports information in direct string value format, hence
> a new interface has been introduced in
> /sys/firmware/papr/energy_scale_info to export this information to
> userspace in an extensible pass-through format.
>
> The H_CALL returns the name, numeric value and string value (if exists)
>
> The format of exposing the sysfs information is as follows:
> /sys/firmware/papr/energy_scale_info/
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc (if exists)
> |-- <id>/
> |-- desc
> |-- value
> |-- value_desc (if exists)
> ...
>
> The energy information that is exported is useful for userspace tools
> such as powerpc-utils. Currently these tools infer the
> "power_mode_data" value in the lparcfg, which in turn is obtained from
> the to be deprecated H_GET_EM_PARMS H_CALL.
> On future platforms, such userspace utilities will have to look at the
> data returned from the new H_CALL being populated in this new sysfs
> interface and report this information directly without the need of
> interpretation.
>
> Signed-off-by: Pratik R. Sampat <psampat@linux.ibm.com>
> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox