* Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
From: heying (H) @ 2021-03-18 2:28 UTC (permalink / raw)
To: Christophe Leroy, mpe, benh, paulus, npiggin, msuchanek, peterz,
geert+renesas, kernelfans, frederic
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3f4d196b-0a8e-d4c9-cabe-591f5916a2b9@csgroup.eu>
在 2021/3/17 19:16, Christophe Leroy 写道:
>
>
> Le 17/03/2021 à 11:34, He Ying a écrit :
>> We found these warnings in arch/powerpc/kernel/time.c as follows:
>> warning: symbol 'decrementer_max' was not declared. Should it be static?
>> warning: symbol 'rtc_lock' was not declared. Should it be static?
>> warning: symbol 'dtl_consumer' was not declared. Should it be static?
>>
>> Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And
>> include
>> proper header in which 'rtc_lock' is declared. Move 'dtl_consumer'
>> definition behind "include <asm/dtl.h>" because 'dtl_consumer' is
>> declared
>> there.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: He Ying <heying24@huawei.com>
>> ---
>> arch/powerpc/include/asm/time.h | 1 +
>> arch/powerpc/kernel/time.c | 7 +++----
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/time.h
>> b/arch/powerpc/include/asm/time.h
>> index 8dd3cdb25338..2cd2b50bedda 100644
>> --- a/arch/powerpc/include/asm/time.h
>> +++ b/arch/powerpc/include/asm/time.h
>> @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
>> extern unsigned long tb_ticks_per_usec;
>> extern unsigned long tb_ticks_per_sec;
>> extern struct clock_event_device decrementer_clockevent;
>> +extern u64 decrementer_max;
>> extern void generic_calibrate_decr(void);
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index b67d93a609a2..409967713ca6 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>> @@ -55,6 +55,7 @@
>> #include <linux/sched/cputime.h>
>> #include <linux/sched/clock.h>
>> #include <linux/processor.h>
>> +#include <linux/mc146818rtc.h>
>
> I don't think that's the good place. It has no link to powerpc, it is
> only by chance that it has the same name.
>
> As rtc_lock is defined in powerpc time.c, I think you should declare
> it in powerpc asm/time.h
My first thought was the same as yours. I tried to add declaration in
powerpc asm/time.h, but got a compiling error:
drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’
follows non-static declaration
static DEFINE_SPINLOCK(rtc_lock);
In file included from ./arch/powerpc/include/asm/delay.h:7:0,
from ./arch/powerpc/include/asm/io.h:33,
from ./include/linux/io.h:13,
from drivers/rtc/rtc-vr41xx.c:11:
./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of
‘rtc_lock’ was here
extern spinlock_t rtc_lock;
There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c.
But I find an existing declaration in linux/mc146818rtc.h and there's
only one definition for 'rtc_lock' in powerpc.
There's some includes of mc146818rtc.h in powperc. I wonder they point
to the same thing. But I'm not very sure
because the header's name looks a bit strange.
>
>
>> #include <asm/trace.h>
>> #include <asm/interrupt.h>
>> @@ -150,10 +151,6 @@ bool tb_invalid;
>> u64 __cputime_usec_factor;
>> EXPORT_SYMBOL(__cputime_usec_factor);
>> -#ifdef CONFIG_PPC_SPLPAR
>> -void (*dtl_consumer)(struct dtl_entry *, u64);
>> -#endif
>> -
>> static void calc_cputime_factors(void)
>> {
>> struct div_result res;
>> @@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned
>> long tb)
>> #include <asm/dtl.h>
>> +void (*dtl_consumer)(struct dtl_entry *, u64);
>> +
>> /*
>> * Scan the dispatch trace log and count up the stolen time.
>> * Should be called with interrupts disabled.
>>
> .
^ permalink raw reply
* Re: [PATCH] powerpc/numa: Fix topology_physical_package_id() on pSeries
From: Michael Ellerman @ 2021-03-18 2:26 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
Cc: Nathan Lynch, Srikar Dronamraju, Daniel Henrique Barboza,
Greg Kurz, Vasant Hegde, Cédric Le Goater, David Gibson
In-Reply-To: <20210312143154.3181109-1-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> Initial commit 15863ff3b8da ("powerpc: Make chip-id information
> available to userspace") introduce a cpu_to_chip_id() routine for the
> PowerNV platform using the "ibm,chip-id" property to query the chip id
> of a CPU. But PAPR does not specify such a property and the node id
> query is broken.
>
> Use cpu_to_node() instead which guarantees to have a correct value on
> all platforms, PowerNV an pSeries.
I'm not convinced this is correct on any platforms :)
The node (nid) is just a number made up by Linux, so it's not a
"physical package id".
It might correspond to a "physical package" (whatever that means), on
existing skiboot, but it's not guaranteed.
The PAPR text around associativity and so on is incredibly dense, but I
think one thing that is clear is that firmware is allowed to present to
us whatever boundaries it thinks are most meaningful.
ie. if two things on one "physical package" have a meaningful distance
between them, then they might be presented to us as two nodes.
Having said that, if you look at the documentation in the kernel we
have:
physical_package_id: physical package id of cpu#. Typically
corresponds to a physical socket number, but the actual value
is architecture and platform dependent.
Which is nicely vague.
But then:
core_siblings: internal kernel map of cpu#'s hardware threads
within the same physical_package_id.
Which is not true for us already on bare metal. And is just wrong on
modern CPUs where there's multiple non-siblings in a single
core/chip/package.
So a patch to update the documentation would be good :)
As far as what we should do in our topology code, I think we should use
the chip-id when we have it - ie. on bare metal.
It may not be exactly correct, but it's at least not filtered through
any indirection about NUMA-ness, ie. the associativity properties.
Also we've been using it for several years and I don't think we should
risk breaking anything by changing the value now.
As far as pseries, I'm still a bit dubious, but maybe using nid is
better than providing nothing, even if it is a lie.
cheers
^ permalink raw reply
* [PATCH 1/2] audit: add support for the openat2 syscall
From: Richard Guy Briggs @ 2021-03-18 1:47 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML
Cc: linux-s390, linux-ia64, Paul Moore, linux-parisc,
Richard Guy Briggs, x86, Eric Paris, linux-fsdevel,
Alexander Viro, linux-alpha, sparclinux, Eric Paris, Steve Grubb,
linuxppc-dev
In-Reply-To: <cover.1616031035.git.rgb@redhat.com>
The openat2(2) syscall was added in kernel v5.6 with commit fddb5d430ad9
("open: introduce openat2(2) syscall")
Add the openat2(2) syscall to the audit syscall classifier.
See the github issue
https://github.com/linux-audit/audit-kernel/issues/67
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
---
arch/alpha/kernel/audit.c | 2 ++
arch/ia64/kernel/audit.c | 2 ++
arch/parisc/kernel/audit.c | 2 ++
arch/parisc/kernel/compat_audit.c | 2 ++
arch/powerpc/kernel/audit.c | 2 ++
arch/powerpc/kernel/compat_audit.c | 2 ++
arch/s390/kernel/audit.c | 2 ++
arch/s390/kernel/compat_audit.c | 2 ++
arch/sparc/kernel/audit.c | 2 ++
arch/sparc/kernel/compat_audit.c | 2 ++
arch/x86/ia32/audit.c | 2 ++
arch/x86/kernel/audit_64.c | 2 ++
kernel/auditsc.c | 3 +++
lib/audit.c | 4 ++++
lib/compat_audit.c | 4 ++++
15 files changed, 35 insertions(+)
diff --git a/arch/alpha/kernel/audit.c b/arch/alpha/kernel/audit.c
index 96a9d18ff4c4..06a911b685d1 100644
--- a/arch/alpha/kernel/audit.c
+++ b/arch/alpha/kernel/audit.c
@@ -42,6 +42,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/ia64/kernel/audit.c b/arch/ia64/kernel/audit.c
index 5192ca899fe6..5eaa888c8fd3 100644
--- a/arch/ia64/kernel/audit.c
+++ b/arch/ia64/kernel/audit.c
@@ -43,6 +43,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/audit.c b/arch/parisc/kernel/audit.c
index 9eb47b2225d2..fc721a7727ba 100644
--- a/arch/parisc/kernel/audit.c
+++ b/arch/parisc/kernel/audit.c
@@ -52,6 +52,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/parisc/kernel/compat_audit.c b/arch/parisc/kernel/compat_audit.c
index 20c39c9d86a9..fc6d35918c44 100644
--- a/arch/parisc/kernel/compat_audit.c
+++ b/arch/parisc/kernel/compat_audit.c
@@ -35,6 +35,8 @@ int parisc32_classify_syscall(unsigned syscall)
return 3;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/powerpc/kernel/audit.c b/arch/powerpc/kernel/audit.c
index a2dddd7f3d09..8f32700b0baa 100644
--- a/arch/powerpc/kernel/audit.c
+++ b/arch/powerpc/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/powerpc/kernel/compat_audit.c b/arch/powerpc/kernel/compat_audit.c
index 55c6ccda0a85..ebe45534b1c9 100644
--- a/arch/powerpc/kernel/compat_audit.c
+++ b/arch/powerpc/kernel/compat_audit.c
@@ -38,6 +38,8 @@ int ppc32_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/s390/kernel/audit.c b/arch/s390/kernel/audit.c
index d395c6c9944c..d964cb94cfaf 100644
--- a/arch/s390/kernel/audit.c
+++ b/arch/s390/kernel/audit.c
@@ -54,6 +54,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/s390/kernel/compat_audit.c b/arch/s390/kernel/compat_audit.c
index 444fb1f66944..f7b32933ce0e 100644
--- a/arch/s390/kernel/compat_audit.c
+++ b/arch/s390/kernel/compat_audit.c
@@ -39,6 +39,8 @@ int s390_classify_syscall(unsigned syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/sparc/kernel/audit.c b/arch/sparc/kernel/audit.c
index a6e91bf34d48..b6dcca9c6520 100644
--- a/arch/sparc/kernel/audit.c
+++ b/arch/sparc/kernel/audit.c
@@ -55,6 +55,8 @@ int audit_classify_syscall(int abi, unsigned int syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/arch/sparc/kernel/compat_audit.c b/arch/sparc/kernel/compat_audit.c
index 10eeb4f15b20..d2652a1083ad 100644
--- a/arch/sparc/kernel/compat_audit.c
+++ b/arch/sparc/kernel/compat_audit.c
@@ -39,6 +39,8 @@ int sparc32_classify_syscall(unsigned int syscall)
return 4;
case __NR_execve:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/x86/ia32/audit.c b/arch/x86/ia32/audit.c
index 6efe6cb3768a..57a02ade5503 100644
--- a/arch/x86/ia32/audit.c
+++ b/arch/x86/ia32/audit.c
@@ -39,6 +39,8 @@ int ia32_classify_syscall(unsigned syscall)
case __NR_execve:
case __NR_execveat:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 1;
}
diff --git a/arch/x86/kernel/audit_64.c b/arch/x86/kernel/audit_64.c
index 83d9cad4e68b..39de1e021258 100644
--- a/arch/x86/kernel/audit_64.c
+++ b/arch/x86/kernel/audit_64.c
@@ -53,6 +53,8 @@ int audit_classify_syscall(int abi, unsigned syscall)
case __NR_execve:
case __NR_execveat:
return 5;
+ case __NR_openat2:
+ return 6;
default:
return 0;
}
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 8bb9ac84d2fb..f5616e70d129 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -76,6 +76,7 @@
#include <linux/fsnotify_backend.h>
#include <uapi/linux/limits.h>
#include <uapi/linux/netfilter/nf_tables.h>
+#include <uapi/linux/openat2.h>
#include "audit.h"
@@ -195,6 +196,8 @@ static int audit_match_perm(struct audit_context *ctx, int mask)
return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] == SYS_BIND);
case 5: /* execve */
return mask & AUDIT_PERM_EXEC;
+ case 6: /* openat2 */
+ return mask & ACC_MODE((u32)((struct open_how *)ctx->argv[2])->flags);
default:
return 0;
}
diff --git a/lib/audit.c b/lib/audit.c
index 5004bff928a7..8f030b9a2d10 100644
--- a/lib/audit.c
+++ b/lib/audit.c
@@ -60,6 +60,10 @@ int audit_classify_syscall(int abi, unsigned syscall)
#endif
case __NR_execve:
return 5;
+#ifdef __NR_openat2
+ case __NR_openat2:
+ return 6;
+#endif
default:
return 0;
}
diff --git a/lib/compat_audit.c b/lib/compat_audit.c
index 77eabad69b4a..8aff0d0d9ba0 100644
--- a/lib/compat_audit.c
+++ b/lib/compat_audit.c
@@ -45,6 +45,10 @@ int audit_classify_compat_syscall(int abi, unsigned syscall)
#endif
case __NR_execve:
return 5;
+#ifdef __NR_openat2
+ case __NR_openat2:
+ return 6;
+#endif
default:
return 1;
}
--
2.27.0
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS 87d76f542a24ecfa797e9bd3bb56c0f19aabff57
From: kernel test robot @ 2021-03-18 1:08 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: 87d76f542a24ecfa797e9bd3bb56c0f19aabff57 Automatic merge of 'fixes' into merge (2021-03-17 14:13)
elapsed time: 1277m
configs tested: 174
configs skipped: 2
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
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc ge_imp3a_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
mips gpr_defconfig
powerpc xes_mpc85xx_defconfig
arm mmp2_defconfig
arm palmz72_defconfig
arm iop32x_defconfig
arm neponset_defconfig
powerpc kilauea_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
sh landisk_defconfig
powerpc mvme5100_defconfig
m68k m5249evb_defconfig
sh titan_defconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
powerpc ppc64_defconfig
powerpc canyonlands_defconfig
arm spear13xx_defconfig
sh sh7785lcr_32bit_defconfig
powerpc mpc832x_mds_defconfig
arm ep93xx_defconfig
mips cobalt_defconfig
sh secureedge5410_defconfig
powerpc asp8347_defconfig
arm tegra_defconfig
powerpc pmac32_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
mips ip28_defconfig
powerpc adder875_defconfig
arm assabet_defconfig
arc alldefconfig
arm multi_v4t_defconfig
sh se7619_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm clps711x_defconfig
powerpc arches_defconfig
sparc sparc32_defconfig
powerpc stx_gp3_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
arm lpc18xx_defconfig
arm lpc32xx_defconfig
sh lboxre2_defconfig
powerpc tqm8541_defconfig
alpha alldefconfig
arm lubbock_defconfig
ia64 zx1_defconfig
powerpc akebono_defconfig
mips cavium_octeon_defconfig
xtensa generic_kc705_defconfig
parisc alldefconfig
arm cerfcube_defconfig
arm collie_defconfig
sh espt_defconfig
xtensa defconfig
arc nsimosci_defconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
xtensa common_defconfig
m68k defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
s390 zfcpdump_defconfig
arm am200epdkit_defconfig
powerpc wii_defconfig
microblaze defconfig
powerpc cm5200_defconfig
powerpc storcenter_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
arc haps_hs_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
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
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 11aa533b82d5785e0475fd1e2f47db1ccf8f5be4
From: kernel test robot @ 2021-03-18 1:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 11aa533b82d5785e0475fd1e2f47db1ccf8f5be4 powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS
elapsed time: 1276m
configs tested: 135
configs skipped: 2
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
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
powerpc ge_imp3a_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
mips gpr_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
mips rt305x_defconfig
arm cm_x300_defconfig
sh defconfig
powerpc mpc834x_itx_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm moxart_defconfig
powerpc wii_defconfig
mips ip32_defconfig
ia64 bigsur_defconfig
arm multi_v7_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
arm palmz72_defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
powerpc adder875_defconfig
powerpc cm5200_defconfig
powerpc storcenter_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
arc haps_hs_defconfig
arm am200epdkit_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
arm collie_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
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
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS cc7a0bb058b85ea03db87169c60c7cfdd5d34678
From: kernel test robot @ 2021-03-18 1:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: cc7a0bb058b85ea03db87169c60c7cfdd5d34678 PCI: rpadlpar: Fix potential drc_name corruption in store functions
elapsed time: 1279m
configs tested: 210
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm allyesconfig
arm allmodconfig
arm64 allyesconfig
arm64 defconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
nds32 alldefconfig
arm pxa255-idp_defconfig
arm lpc32xx_defconfig
sh sh7710voipgw_defconfig
powerpc ge_imp3a_defconfig
arm am200epdkit_defconfig
powerpc skiroot_defconfig
powerpc ksi8560_defconfig
sh se7721_defconfig
m68k defconfig
h8300 edosk2674_defconfig
powerpc redwood_defconfig
mips qi_lb60_defconfig
powerpc taishan_defconfig
powerpc allmodconfig
mips gpr_defconfig
powerpc socrates_defconfig
arc haps_hs_defconfig
arm spear13xx_defconfig
powerpc mpc512x_defconfig
powerpc xes_mpc85xx_defconfig
arm mmp2_defconfig
arm palmz72_defconfig
arm iop32x_defconfig
arm neponset_defconfig
powerpc kilauea_defconfig
arm bcm2835_defconfig
sh rsk7269_defconfig
sh se7751_defconfig
parisc generic-64bit_defconfig
powerpc mpc85xx_cds_defconfig
arm alldefconfig
sh landisk_defconfig
powerpc mvme5100_defconfig
m68k m5249evb_defconfig
sh titan_defconfig
powerpc ppc40x_defconfig
sh edosk7705_defconfig
s390 debug_defconfig
sh apsh4a3a_defconfig
m68k mvme16x_defconfig
m68k bvme6000_defconfig
powerpc mpc832x_mds_defconfig
arm ep93xx_defconfig
mips cobalt_defconfig
sh secureedge5410_defconfig
powerpc asp8347_defconfig
arm tegra_defconfig
powerpc pmac32_defconfig
arm rpc_defconfig
arc tb10x_defconfig
xtensa audio_kc705_defconfig
sh se7750_defconfig
arc nsim_700_defconfig
arm pxa910_defconfig
powerpc makalu_defconfig
sh se7206_defconfig
sh se7724_defconfig
arm cns3420vb_defconfig
mips rs90_defconfig
arm simpad_defconfig
mips gcw0_defconfig
powerpc eiger_defconfig
mips bmips_be_defconfig
m68k stmark2_defconfig
powerpc wii_defconfig
mips loongson1c_defconfig
sh sh7785lcr_defconfig
mips ip28_defconfig
powerpc adder875_defconfig
arm assabet_defconfig
arc alldefconfig
arm multi_v4t_defconfig
sh se7619_defconfig
sh sdk7786_defconfig
mips mpc30x_defconfig
powerpc mpc836x_mds_defconfig
arm clps711x_defconfig
powerpc arches_defconfig
sparc sparc32_defconfig
powerpc stx_gp3_defconfig
arm imx_v4_v5_defconfig
powerpc chrp32_defconfig
mips loongson1b_defconfig
h8300 h8300h-sim_defconfig
sh sh7757lcr_defconfig
sh alldefconfig
powerpc storcenter_defconfig
arm milbeaut_m10v_defconfig
mips ath79_defconfig
powerpc pcm030_defconfig
arm eseries_pxa_defconfig
powerpc lite5200b_defconfig
powerpc ppa8548_defconfig
powerpc ebony_defconfig
arm footbridge_defconfig
mips bcm47xx_defconfig
powerpc mpc7448_hpc2_defconfig
xtensa defconfig
arm lpc18xx_defconfig
sh lboxre2_defconfig
alpha allyesconfig
powerpc tqm8541_defconfig
alpha alldefconfig
arm lubbock_defconfig
ia64 zx1_defconfig
sh espt_defconfig
arc nsimosci_defconfig
parisc allyesconfig
powerpc sam440ep_defconfig
powerpc mpc8560_ads_defconfig
arm ixp4xx_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
powerpc motionpro_defconfig
nios2 alldefconfig
mips ip27_defconfig
xtensa common_defconfig
nios2 3c120_defconfig
mips ar7_defconfig
mips maltaup_defconfig
arm stm32_defconfig
mips ath25_defconfig
powerpc64 alldefconfig
s390 zfcpdump_defconfig
microblaze defconfig
powerpc cm5200_defconfig
sh sh7770_generic_defconfig
mips maltaup_xpa_defconfig
mips malta_kvm_defconfig
arm lart_defconfig
arm spitz_defconfig
sh sh7785lcr_32bit_defconfig
arm vf610m4_defconfig
xtensa alldefconfig
arm collie_defconfig
sh sh7763rdp_defconfig
powerpc sbc8548_defconfig
arm exynos_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210317
x86_64 randconfig-a001-20210317
x86_64 randconfig-a005-20210317
x86_64 randconfig-a004-20210317
x86_64 randconfig-a003-20210317
x86_64 randconfig-a002-20210317
i386 randconfig-a001-20210317
i386 randconfig-a005-20210317
i386 randconfig-a002-20210317
i386 randconfig-a003-20210317
i386 randconfig-a004-20210317
i386 randconfig-a006-20210317
i386 randconfig-a013-20210317
i386 randconfig-a016-20210317
i386 randconfig-a011-20210317
i386 randconfig-a012-20210317
i386 randconfig-a015-20210317
i386 randconfig-a014-20210317
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20210317
x86_64 randconfig-a016-20210317
x86_64 randconfig-a013-20210317
x86_64 randconfig-a014-20210317
x86_64 randconfig-a015-20210317
x86_64 randconfig-a012-20210317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Kefeng Wang @ 2021-03-18 1:01 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, Andrew Morton
Cc: linux-ia64, linux-sh, Peter Zijlstra, Catalin Marinas,
Dave Hansen, linux-mm, Guo Ren, sparclinux, linux-riscv,
Jonas Bonn, linux-s390, Yoshinori Sato, linux-hexagon,
Huacai Chen, Russell King, linux-csky, Ingo Molnar,
linux-snps-arc, linux-xtensa, Heiko Carstens, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Richard Henderson,
linux-parisc, linux-mips, Palmer Dabbelt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <2a7d6e39-b293-7422-87b0-741f1ab0c22c@intel.com>
On 2021/3/18 2:48, Dave Hansen wrote:
> On 3/16/21 6:52 PM, Kefeng Wang wrote:
>> mem_init_print_info() is called in mem_init() on each architecture,
>> and pass NULL argument, so using void argument and move it into mm_init().
>>
>> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> It's not a big deal but you might want to say something like:
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 bits
>
> Just to make it clear that I didn't look at the alpha bits at all. :)
Get it, will be careful, thanks.
> .
>
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Vineet Gupta @ 2021-03-18 0:40 UTC (permalink / raw)
To: Kefeng Wang, linux-kernel@vger.kernel.org, Andrew Morton
Cc: linux-ia64@vger.kernel.org, Peter Zijlstra, Catalin Marinas,
Dave Hansen, Guo Ren, Jonas Bonn, Yoshinori Sato,
linux-hexagon@vger.kernel.org, Huacai Chen, Russell King,
linux-csky@vger.kernel.org, linux-riscv@lists.infradea,
Ingo Molnar, linux-snps-arc@lists.infradead.org, Heiko Carstens,
linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org,
linux-arm-kernel@lists.infradead.org, Richard Henderson,
linux-parisc@vger.kernel.org, linux-mips@vger.kernel.org,
Palmer Dabbelt, linux-alpha@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <20210317015210.33641-1-wangkefeng.wang@huawei.com>
On 3/16/21 6:52 PM, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
Thx,
-Vineet
^ permalink raw reply
* Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
From: Nicholas Piggin @ 2021-03-17 22:41 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <87o8fh21iq.fsf@linux.ibm.com>
Excerpts from Fabiano Rosas's message of March 18, 2021 2:22 am:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
>> In the interest of minimising the amount of code that is run in
>> "real-mode", don't handle hcalls in real mode in the P9 path.
>>
>> POWER8 and earlier are much more expensive to exit from HV real mode
>> and switch to host mode, because on those processors HV interrupts get
>> to the hypervisor with the MMU off, and the other threads in the core
>> need to be pulled out of the guest, and SLBs all need to be saved,
>> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
>> in host mode. Hash guests also require a lot of hcalls to run. The
>> XICS interrupt controller requires hcalls to run.
>>
>> By contrast, POWER9 has independent thread switching, and in radix mode
>> the hypervisor is already in a host virtual memory mode when the HV
>> interrupt is taken. Radix + xive guests don't need hcalls to handle
>> interrupts or manage translations.
>>
>> So it's much less important to handle hcalls in real mode in P9.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>
> <snip>
>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 497f216ad724..1f2ba8955c6a 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
>> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
>> * that the cede logic in kvmppc_run_single_vcpu() works properly.
>> */
>> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
>> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
>
> The comment above needs to be updated I think.
>
>> {
>> vcpu->arch.shregs.msr |= MSR_EE;
>> vcpu->arch.ceded = 1;
>> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu *vcpu,
>> /* hcall - punt to userspace */
>> int i;
>>
>> - /* hypercall with MSR_PR has already been handled in rmode,
>> - * and never reaches here.
>> - */
>> + if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
>> + /*
>> + * Guest userspace executed sc 1, reflect it back as a
>> + * privileged program check interrupt.
>> + */
>> + kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
>> + r = RESUME_GUEST;
>> + break;
>> + }
>>
>> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
>> for (i = 0; i < 9; ++i)
>> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
>> /* H_CEDE has to be handled now, not later */
>> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
>> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
>> - kvmppc_nested_cede(vcpu);
>> + kvmppc_cede(vcpu);
>> kvmppc_set_gpr(vcpu, 3, 0);
>> trap = 0;
>> }
>> } else {
>> kvmppc_xive_push_vcpu(vcpu);
>> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
>> - kvmppc_xive_pull_vcpu(vcpu);
>> + /* H_CEDE has to be handled now, not later */
>> + /* XICS hcalls must be handled before xive is pulled */
>> + if (trap == BOOK3S_INTERRUPT_SYSCALL &&
>> + !(vcpu->arch.shregs.msr & MSR_PR)) {
>> + unsigned long req = kvmppc_get_gpr(vcpu, 3);
>>
>> + if (req == H_CEDE) {
>> + kvmppc_cede(vcpu);
>> + kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
>> + kvmppc_set_gpr(vcpu, 3, 0);
>> + trap = 0;
>> + }
>> + if (req == H_EOI || req == H_CPPR ||
>> + req == H_IPI || req == H_IPOLL ||
>> + req == H_XIRR || req == H_XIRR_X) {
>> + unsigned long ret;
>> +
>> + ret = kvmppc_xive_xics_hcall(vcpu, req);
>> + kvmppc_set_gpr(vcpu, 3, ret);
>> + trap = 0;
>> + }
>> + }
>
> I tried running L2 with xive=off and this code slows down the boot
> considerably. I think we're missing a !vcpu->arch.nested in the
> conditional.
You might be right, the real mode handlers never run if nested is set
so none of these should run I think.
>
> This may also be missing these checks from kvmppc_pseries_do_hcall:
>
> if (kvmppc_xics_enabled(vcpu)) {
> if (xics_on_xive()) {
> ret = H_NOT_AVAILABLE;
> return RESUME_GUEST;
> }
> ret = kvmppc_xics_hcall(vcpu, req);
> (...)
Well this is the formerly real-mode part of the hcall, whereas
pseries_do_hcall is the virt-mode handler so it expects the real mode
has already run.
Hmm, probably it shouldn't be setting trap = 0 if it did not handle the
hcall. I don't know if that's the problem you have or if it's the nested
test but probably should test for this anyway.
> For H_CEDE there might be a similar situation since we're shadowing the
> code above that runs after H_ENTER_NESTED by setting trap to 0 here.
Yes.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Dave Hansen @ 2021-03-17 18:48 UTC (permalink / raw)
To: Kefeng Wang, linux-kernel, Andrew Morton
Cc: linux-ia64, linux-sh, Peter Zijlstra, Catalin Marinas,
Dave Hansen, linux-mm, Guo Ren, sparclinux, linux-riscv,
Jonas Bonn, linux-s390, Yoshinori Sato, linux-hexagon,
Huacai Chen, Russell King, linux-csky, Ingo Molnar,
linux-snps-arc, linux-xtensa, Heiko Carstens, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Richard Henderson,
linux-parisc, linux-mips, Palmer Dabbelt, linux-alpha,
linuxppc-dev, David S. Miller
In-Reply-To: <20210317015210.33641-1-wangkefeng.wang@huawei.com>
On 3/16/21 6:52 PM, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
It's not a big deal but you might want to say something like:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86 bits
Just to make it clear that I didn't look at the alpha bits at all. :)
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Konrad Rzeszutek Wilk @ 2021-03-17 18:18 UTC (permalink / raw)
To: Christoph Hellwig, jgross
Cc: xen-devel, iommu, Dongli Zhang, Claire Chang, linuxppc-dev
In-Reply-To: <20210317175742.GA29280@lst.de>
On Wed, Mar 17, 2021 at 06:57:42PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > > - if (!io_tlb_alloc_size)
> > > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > > - __func__, alloc_size, PAGE_SIZE);
> > > >
> > > > Shouldn't this be converted to:
> > > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > if (...)
> > > >
> > > > Seems that it got lost in the search and replace?
> > >
> > > Yes, I messed that up during the rebase. That being said it magically
> > > gets fixed in the next patch..
> >
> > Yes. However if someone does a bisection they are going to be mighty unhappy
> > with you.
>
> Sure, I was planning on fixing it anyway. Just waiting for feedback
> on the rest of the patches before doing a respin.
I put the patches up-to this one on :
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb devel/for-linus-5.13
Would you be OK rebasing on top of that and sending the patches?
Juergen, would you be OK testing that branch on your Xen setup?
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Christoph Hellwig @ 2021-03-17 17:57 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Dongli Zhang, iommu, xen-devel, Claire Chang, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <YFJBvFjtZUiBQj4k@Konrads-MacBook-Pro.local>
On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > > - if (!io_tlb_alloc_size)
> > > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > > - __func__, alloc_size, PAGE_SIZE);
> > >
> > > Shouldn't this be converted to:
> > > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > if (...)
> > >
> > > Seems that it got lost in the search and replace?
> >
> > Yes, I messed that up during the rebase. That being said it magically
> > gets fixed in the next patch..
>
> Yes. However if someone does a bisection they are going to be mighty unhappy
> with you.
Sure, I was planning on fixing it anyway. Just waiting for feedback
on the rest of the patches before doing a respin.
^ permalink raw reply
* Re: [PATCH] powerpc: kernel: Trivial typo fix in the file kgdb.c
From: Randy Dunlap @ 2021-03-17 17:56 UTC (permalink / raw)
To: Bhaskar Chowdhury, mpe, benh, paulus, jniethe5, alistair,
linuxppc-dev, linux-kernel
In-Reply-To: <20210317090413.120891-1-unixbhaskar@gmail.com>
On 3/17/21 2:04 AM, Bhaskar Chowdhury wrote:
>
> s/procesing/processing/
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> arch/powerpc/kernel/kgdb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 409080208a6c..7dd2ad3603ad 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -376,7 +376,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long pc)
> }
>
> /*
> - * This function does PowerPC specific procesing for interfacing to gdb.
> + * This function does PowerPC specific processing for interfacing to gdb.
> */
> int kgdb_arch_handle_exception(int vector, int signo, int err_code,
> char *remcom_in_buffer, char *remcom_out_buffer,
> --
--
~Randy
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Konrad Rzeszutek Wilk @ 2021-03-17 17:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, iommu, Dongli Zhang, Claire Chang, linuxppc-dev
In-Reply-To: <20210317135327.GA10797@lst.de>
On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > > - if (!io_tlb_alloc_size)
> > > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > > - __func__, alloc_size, PAGE_SIZE);
> >
> > Shouldn't this be converted to:
> > mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > if (...)
> >
> > Seems that it got lost in the search and replace?
>
> Yes, I messed that up during the rebase. That being said it magically
> gets fixed in the next patch..
Yes. However if someone does a bisection they are going to be mighty unhappy
with you.
^ permalink raw reply
* Re: [PATCH v3 19/41] KVM: PPC: Book3S HV P9: Stop handling hcalls in real-mode in the P9 path
From: Fabiano Rosas @ 2021-03-17 16:22 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210305150638.2675513-20-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> In the interest of minimising the amount of code that is run in
> "real-mode", don't handle hcalls in real mode in the P9 path.
>
> POWER8 and earlier are much more expensive to exit from HV real mode
> and switch to host mode, because on those processors HV interrupts get
> to the hypervisor with the MMU off, and the other threads in the core
> need to be pulled out of the guest, and SLBs all need to be saved,
> ERATs invalidated, and host SLB reloaded before the MMU is re-enabled
> in host mode. Hash guests also require a lot of hcalls to run. The
> XICS interrupt controller requires hcalls to run.
>
> By contrast, POWER9 has independent thread switching, and in radix mode
> the hypervisor is already in a host virtual memory mode when the HV
> interrupt is taken. Radix + xive guests don't need hcalls to handle
> interrupts or manage translations.
>
> So it's much less important to handle hcalls in real mode in P9.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
<snip>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 497f216ad724..1f2ba8955c6a 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1147,7 +1147,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
> * This has to be done early, not in kvmppc_pseries_do_hcall(), so
> * that the cede logic in kvmppc_run_single_vcpu() works properly.
> */
> -static void kvmppc_nested_cede(struct kvm_vcpu *vcpu)
> +static void kvmppc_cede(struct kvm_vcpu *vcpu)
The comment above needs to be updated I think.
> {
> vcpu->arch.shregs.msr |= MSR_EE;
> vcpu->arch.ceded = 1;
> @@ -1403,9 +1403,15 @@ static int kvmppc_handle_exit_hv(struct kvm_vcpu *vcpu,
> /* hcall - punt to userspace */
> int i;
>
> - /* hypercall with MSR_PR has already been handled in rmode,
> - * and never reaches here.
> - */
> + if (unlikely(vcpu->arch.shregs.msr & MSR_PR)) {
> + /*
> + * Guest userspace executed sc 1, reflect it back as a
> + * privileged program check interrupt.
> + */
> + kvmppc_core_queue_program(vcpu, SRR1_PROGPRIV);
> + r = RESUME_GUEST;
> + break;
> + }
>
> run->papr_hcall.nr = kvmppc_get_gpr(vcpu, 3);
> for (i = 0; i < 9; ++i)
> @@ -3740,15 +3746,36 @@ static int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit,
> /* H_CEDE has to be handled now, not later */
> if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&
> kvmppc_get_gpr(vcpu, 3) == H_CEDE) {
> - kvmppc_nested_cede(vcpu);
> + kvmppc_cede(vcpu);
> kvmppc_set_gpr(vcpu, 3, 0);
> trap = 0;
> }
> } else {
> kvmppc_xive_push_vcpu(vcpu);
> trap = kvmhv_load_hv_regs_and_go(vcpu, time_limit, lpcr);
> - kvmppc_xive_pull_vcpu(vcpu);
> + /* H_CEDE has to be handled now, not later */
> + /* XICS hcalls must be handled before xive is pulled */
> + if (trap == BOOK3S_INTERRUPT_SYSCALL &&
> + !(vcpu->arch.shregs.msr & MSR_PR)) {
> + unsigned long req = kvmppc_get_gpr(vcpu, 3);
>
> + if (req == H_CEDE) {
> + kvmppc_cede(vcpu);
> + kvmppc_xive_cede_vcpu(vcpu); /* may un-cede */
> + kvmppc_set_gpr(vcpu, 3, 0);
> + trap = 0;
> + }
> + if (req == H_EOI || req == H_CPPR ||
> + req == H_IPI || req == H_IPOLL ||
> + req == H_XIRR || req == H_XIRR_X) {
> + unsigned long ret;
> +
> + ret = kvmppc_xive_xics_hcall(vcpu, req);
> + kvmppc_set_gpr(vcpu, 3, ret);
> + trap = 0;
> + }
> + }
I tried running L2 with xive=off and this code slows down the boot
considerably. I think we're missing a !vcpu->arch.nested in the
conditional.
This may also be missing these checks from kvmppc_pseries_do_hcall:
if (kvmppc_xics_enabled(vcpu)) {
if (xics_on_xive()) {
ret = H_NOT_AVAILABLE;
return RESUME_GUEST;
}
ret = kvmppc_xics_hcall(vcpu, req);
(...)
For H_CEDE there might be a similar situation since we're shadowing the
code above that runs after H_ENTER_NESTED by setting trap to 0 here.
> + kvmppc_xive_pull_vcpu(vcpu);
> }
>
> vcpu->arch.slb_max = 0;
> @@ -4408,8 +4435,11 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
> else
> r = kvmppc_run_vcpu(vcpu);
>
> - if (run->exit_reason == KVM_EXIT_PAPR_HCALL &&
> - !(vcpu->arch.shregs.msr & MSR_PR)) {
> + if (run->exit_reason == KVM_EXIT_PAPR_HCALL) {
> + if (WARN_ON_ONCE(vcpu->arch.shregs.msr & MSR_PR)) {
> + r = RESUME_GUEST;
> + continue;
> + }
> trace_kvm_hcall_enter(vcpu);
> r = kvmppc_pseries_do_hcall(vcpu);
> trace_kvm_hcall_exit(vcpu, r);
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index c11597f815e4..2d0d14ed1d92 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1397,9 +1397,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> mr r4,r9
> bge fast_guest_return
> 2:
> + /* If we came in through the P9 short path, no real mode hcalls */
> + lwz r0, STACK_SLOT_SHORT_PATH(r1)
> + cmpwi r0, 0
> + bne no_try_real
> /* See if this is an hcall we can handle in real mode */
> cmpwi r12,BOOK3S_INTERRUPT_SYSCALL
> beq hcall_try_real_mode
> +no_try_real:
>
> /* Hypervisor doorbell - exit only if host IPI flag set */
> cmpwi r12, BOOK3S_INTERRUPT_H_DOORBELL
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 52cdb9e2660a..1e4871bbcad4 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -158,6 +158,40 @@ void kvmppc_xive_pull_vcpu(struct kvm_vcpu *vcpu)
> }
> EXPORT_SYMBOL_GPL(kvmppc_xive_pull_vcpu);
>
> +void kvmppc_xive_cede_vcpu(struct kvm_vcpu *vcpu)
> +{
> + void __iomem *esc_vaddr = (void __iomem *)vcpu->arch.xive_esc_vaddr;
> +
> + if (!esc_vaddr)
> + return;
> +
> + /* we are using XIVE with single escalation */
> +
> + if (vcpu->arch.xive_esc_on) {
> + /*
> + * If we still have a pending escalation, abort the cede,
> + * and we must set PQ to 10 rather than 00 so that we don't
> + * potentially end up with two entries for the escalation
> + * interrupt in the XIVE interrupt queue. In that case
> + * we also don't want to set xive_esc_on to 1 here in
> + * case we race with xive_esc_irq().
> + */
> + vcpu->arch.ceded = 0;
> + /*
> + * The escalation interrupts are special as we don't EOI them.
> + * There is no need to use the load-after-store ordering offset
> + * to set PQ to 10 as we won't use StoreEOI.
> + */
> + __raw_readq(esc_vaddr + XIVE_ESB_SET_PQ_10);
> + } else {
> + vcpu->arch.xive_esc_on = true;
> + mb();
> + __raw_readq(esc_vaddr + XIVE_ESB_SET_PQ_00);
> + }
> + mb();
> +}
> +EXPORT_SYMBOL_GPL(kvmppc_xive_cede_vcpu);
> +
> /*
> * This is a simple trigger for a generic XIVE IRQ. This must
> * only be called for interrupts that support a trigger page
> @@ -2106,6 +2140,32 @@ static int kvmppc_xive_create(struct kvm_device *dev, u32 type)
> return 0;
> }
>
> +int kvmppc_xive_xics_hcall(struct kvm_vcpu *vcpu, u32 req)
> +{
> + struct kvmppc_vcore *vc = vcpu->arch.vcore;
> +
> + switch (req) {
> + case H_XIRR:
> + return xive_vm_h_xirr(vcpu);
> + case H_CPPR:
> + return xive_vm_h_cppr(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_EOI:
> + return xive_vm_h_eoi(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_IPI:
> + return xive_vm_h_ipi(vcpu, kvmppc_get_gpr(vcpu, 4),
> + kvmppc_get_gpr(vcpu, 5));
> + case H_IPOLL:
> + return xive_vm_h_ipoll(vcpu, kvmppc_get_gpr(vcpu, 4));
> + case H_XIRR_X:
> + xive_vm_h_xirr(vcpu);
> + kvmppc_set_gpr(vcpu, 5, get_tb() + vc->tb_offset);
> + return H_SUCCESS;
> + }
> +
> + return H_UNSUPPORTED;
> +}
> +EXPORT_SYMBOL_GPL(kvmppc_xive_xics_hcall);
> +
> int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu)
> {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
^ permalink raw reply
* Re: Advice needed on SMP regression after cpu_core_mask change
From: Daniel Henrique Barboza @ 2021-03-17 16:05 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
Cc: Greg Kurz, aneesh.kumar, Srikar Dronamraju, David Gibson
In-Reply-To: <4569097d-ce89-5a13-33a9-2a4ca10be7bd@kaod.org>
On 3/17/21 12:30 PM, Cédric Le Goater wrote:
> On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
>> Hello,
>>
>> Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
>> a regression in both upstream and RHEL downstream kernels [1]. The assumption made
>> in the commit:
>>
>> "Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
>> equal on Power"
>>
>> Doesn't seem to be true. After this commit, QEMU is now unable to set single NUMA
>> node SMP topologies such as:
>>
>> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>>
>> lscpu will give the following output in this case:
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 4
>> Socket(s): 1
>> NUMA node(s): 1
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-7
>>
>>
>> This is happening because the macro cpu_cpu_mask(cpu) expands to
>> cpumask_of_node(cpu_to_node(cpu)), which in turn expands to node_to_cpumask_map[node].
>> node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on CC to
>> correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
>>
>> If I add a second NUMA node then I can get the intended smp topology:
>>
>> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
>> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 2
>> Socket(s): 2
>> NUMA node(s): 2
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-3
>> NUMA node1 CPU(s): 4-7
>>
>>
>> However, if I try a single socket with multiple NUMA nodes topology, which is the case
>> of Power10, e.g.:
>>
>>
>> -smp 8,maxcpus=8,cores=4,threads=2,sockets=1
>> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
>> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>>
>>
>> This is the result:
>>
>> # lscpu
>> Architecture: ppc64le
>> Byte Order: Little Endian
>> CPU(s): 8
>> On-line CPU(s) list: 0-7
>> Thread(s) per core: 2
>> Core(s) per socket: 2
>> Socket(s): 2
>> NUMA node(s): 2
>> Model: 2.2 (pvr 004e 1202)
>> Model name: POWER9 (architected), altivec supported
>> Hypervisor vendor: KVM
>> Virtualization type: para
>> L1d cache: 32K
>> L1i cache: 32K
>> NUMA node0 CPU(s): 0-3
>> NUMA node1 CPU(s): 4-7
>>
>>
>> This confirms my suspicions that, at this moment, we're making sockets == NUMA nodes.
>
> Yes. I don't think we can do better on PAPR and the above examples
> seem to confirm that the "sockets" definition is simply ignored.
>
>> Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The commit
>> after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop updating
>> cpu_core_mask"), is erasing the code that calculated cpu_core_mask. cpu_core_mask, despite
>> its shortcomings that caused its removal, was giving a precise SMP topology. And it was
>> using physical_package_id/'ibm,chip-id' for that.
>
> ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
> is hiding a lot of the underlying HW and topology. May be we are trying
> to reconcile two orthogonal views of machine virtualization ...
>
>> Checking in QEMU I can say that the ibm,chip-id calculation is the only place in the code
>> that cares about cores per socket information. The kernel is now ignoring that, starting
>> on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
>>
>> If we're not going to use ibm,chip-id any longer, which seems sensible given that PAPR does
>> not declare it, we need another way of letting the guest know how much cores per socket
>> we want.
> The RTAS call "ibm,get-system-parameter" with token "Processor Module
> Information" returns that kind of information :
>
> 2 byte binary number (N) of module types followed by N module specifiers of the form:
> 2 byte binary number (M) of sockets of this module type
> 2 byte binary number (L) of chips per this module type
> 2 byte binary number (K) of cores per chip in this module type.
>
> See the values in these sysfs files :
>
> cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
>
> But I am afraid these are host level information and not guest/LPAR.
I believe there might be some sort of reasoning behind not having this on
PAPR, but I'll say in advance that the virtual machine should act as the
real hardware, as close as possible. This is the kind of hcall that could
be used in this situation.
>
> I didn't find any LPAR level properties or hcalls in the PAPR document.
> They need to be specified.
>
> or
>
> We can add extra properties like ibm,chip-id but making sure it's only
> used under the KVM hypervisor. My understanding is that's something we
> are trying to avoid.
We can change PAPR to add ibm,chip-id. Problem is that ibm,chip-id today, with
the current kernel codebase, does not fix the issue because the code is
ignoring it hehehe
If we're going to change PAPR - and I believe we should, there's a clear
lack of proper support for SMP topologies - we're better make sure that whatever
attribute/hcall we add there fixes it in a robust way for the long term.
Thanks,
DHB
>
> C.
>
^ permalink raw reply
* Re: Advice needed on SMP regression after cpu_core_mask change
From: Cédric Le Goater @ 2021-03-17 15:30 UTC (permalink / raw)
To: Daniel Henrique Barboza, linuxppc-dev
Cc: Greg Kurz, aneesh.kumar, Srikar Dronamraju, David Gibson
In-Reply-To: <daa5d05f-dbd0-05ad-7395-5d5a3d364fc6@gmail.com>
On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
> Hello,
>
> Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
> a regression in both upstream and RHEL downstream kernels [1]. The assumption made
> in the commit:
>
> "Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
> equal on Power"
>
> Doesn't seem to be true. After this commit, QEMU is now unable to set single NUMA
> node SMP topologies such as:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
>
> lscpu will give the following output in this case:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 4
> Socket(s): 1
> NUMA node(s): 1
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-7
>
>
> This is happening because the macro cpu_cpu_mask(cpu) expands to
> cpumask_of_node(cpu_to_node(cpu)), which in turn expands to node_to_cpumask_map[node].
> node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on CC to
> correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
>
> If I add a second NUMA node then I can get the intended smp topology:
>
> -smp 8,maxcpus=8,cores=2,threads=2,sockets=2
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> However, if I try a single socket with multiple NUMA nodes topology, which is the case
> of Power10, e.g.:
>
>
> -smp 8,maxcpus=8,cores=4,threads=2,sockets=1
> -numa node,memdev=mem0,cpus=0-3,nodeid=0 \
> -numa node,memdev=mem1,cpus=4-7,nodeid=1 \
>
>
> This is the result:
>
> # lscpu
> Architecture: ppc64le
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 2
> NUMA node(s): 2
> Model: 2.2 (pvr 004e 1202)
> Model name: POWER9 (architected), altivec supported
> Hypervisor vendor: KVM
> Virtualization type: para
> L1d cache: 32K
> L1i cache: 32K
> NUMA node0 CPU(s): 0-3
> NUMA node1 CPU(s): 4-7
>
>
> This confirms my suspicions that, at this moment, we're making sockets == NUMA nodes.
Yes. I don't think we can do better on PAPR and the above examples
seem to confirm that the "sockets" definition is simply ignored.
> Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The commit
> after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop updating
> cpu_core_mask"), is erasing the code that calculated cpu_core_mask. cpu_core_mask, despite
> its shortcomings that caused its removal, was giving a precise SMP topology. And it was
> using physical_package_id/'ibm,chip-id' for that.
ibm,chip-id is a no-no on pSeries. I guess this is inherent to PAPR which
is hiding a lot of the underlying HW and topology. May be we are trying
to reconcile two orthogonal views of machine virtualization ...
> Checking in QEMU I can say that the ibm,chip-id calculation is the only place in the code
> that cares about cores per socket information. The kernel is now ignoring that, starting
> on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
>
> If we're not going to use ibm,chip-id any longer, which seems sensible given that PAPR does
> not declare it, we need another way of letting the guest know how much cores per socket
> we want.
The RTAS call "ibm,get-system-parameter" with token "Processor Module
Information" returns that kind of information :
2 byte binary number (N) of module types followed by N module specifiers of the form:
2 byte binary number (M) of sockets of this module type
2 byte binary number (L) of chips per this module type
2 byte binary number (K) of cores per chip in this module type.
See the values in these sysfs files :
cat /sys/devices/hv_24x7/interface/{sockets,chipspersocket,coresperchip}
But I am afraid these are host level information and not guest/LPAR.
I didn't find any LPAR level properties or hcalls in the PAPR document.
They need to be specified.
or
We can add extra properties like ibm,chip-id but making sure it's only
used under the KVM hypervisor. My understanding is that's something we
are trying to avoid.
C.
^ permalink raw reply
* Re: [PATCH v3 34/41] KVM: PPC: Book3S HV: Remove support for dependent threads mode on P9
From: Aneesh Kumar K.V @ 2021-03-17 15:11 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210305150638.2675513-35-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> Radix guest support will be removed from the P7/8 path, so disallow
> dependent threads mode on P9.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 -
> arch/powerpc/kvm/book3s_hv.c | 27 +++++----------------------
> 2 files changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 05fb00d37609..dd017dfa4e65 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -304,7 +304,6 @@ struct kvm_arch {
> u8 fwnmi_enabled;
> u8 secure_guest;
> u8 svm_enabled;
> - bool threads_indep;
> bool nested_enable;
> bool dawr1_enabled;
> pgd_t *pgtable;
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index cb428e2f7140..928ed8180d9d 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -103,13 +103,9 @@ static int target_smt_mode;
> module_param(target_smt_mode, int, 0644);
> MODULE_PARM_DESC(target_smt_mode, "Target threads per core (0 = max)");
>
> -static bool indep_threads_mode = true;
> -module_param(indep_threads_mode, bool, S_IRUGO | S_IWUSR);
> -MODULE_PARM_DESC(indep_threads_mode, "Independent-threads mode (only on POWER9)");
> -
> static bool one_vm_per_core;
> module_param(one_vm_per_core, bool, S_IRUGO | S_IWUSR);
> -MODULE_PARM_DESC(one_vm_per_core, "Only run vCPUs from the same VM on a core (requires indep_threads_mode=N)");
> +MODULE_PARM_DESC(one_vm_per_core, "Only run vCPUs from the same VM on a core (requires POWER8 or older)");
Isn't this also a security feature, where there was an ask to make sure
threads/vCPU from other VM won't run on this core? In that context isn't
this applicable also for P9?
>
> #ifdef CONFIG_KVM_XICS
> static const struct kernel_param_ops module_param_ops = {
> @@ -2227,7 +2223,7 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
> */
> static int threads_per_vcore(struct kvm *kvm)
> {
> - if (kvm->arch.threads_indep)
> + if (cpu_has_feature(CPU_FTR_ARCH_300))
> return 1;
> return threads_per_subcore;
> }
> @@ -4319,7 +4315,7 @@ static int kvmppc_vcpu_run_hv(struct kvm_vcpu *vcpu)
> vcpu->arch.state = KVMPPC_VCPU_BUSY_IN_HOST;
>
> do {
> - if (kvm->arch.threads_indep && kvm_is_radix(kvm))
> + if (kvm_is_radix(kvm))
> r = kvmhv_run_single_vcpu(vcpu, ~(u64)0,
> vcpu->arch.vcore->lpcr);
> else
> @@ -4934,21 +4930,8 @@ static int kvmppc_core_init_vm_hv(struct kvm *kvm)
> /*
> * Track that we now have a HV mode VM active. This blocks secondary
> * CPU threads from coming online.
> - * On POWER9, we only need to do this if the "indep_threads_mode"
> - * module parameter has been set to N.
> */
> - if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> - if (!indep_threads_mode && !cpu_has_feature(CPU_FTR_HVMODE)) {
> - pr_warn("KVM: Ignoring indep_threads_mode=N in nested hypervisor\n");
> - kvm->arch.threads_indep = true;
> - } else if (!indep_threads_mode && cpu_has_feature(CPU_FTR_P9_RADIX_PREFETCH_BUG)) {
> - pr_warn("KVM: Ignoring indep_threads_mode=N on pre-DD2.2 POWER9\n");
> - kvm->arch.threads_indep = true;
> - } else {
> - kvm->arch.threads_indep = indep_threads_mode;
> - }
> - }
> - if (!kvm->arch.threads_indep)
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> kvm_hv_vm_activated();
>
> /*
> @@ -4989,7 +4972,7 @@ static void kvmppc_core_destroy_vm_hv(struct kvm *kvm)
> {
> debugfs_remove_recursive(kvm->arch.debugfs_dir);
>
> - if (!kvm->arch.threads_indep)
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> kvm_hv_vm_deactivated();
>
> kvmppc_free_vcores(kvm);
> --
> 2.23.0
^ permalink raw reply
* Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
From: Anatoly Pugachev @ 2021-03-17 14:03 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-ia64, linux-sh, Peter Zijlstra, Catalin Marinas,
Dave Hansen, linux-mips, linux-mm, Guo Ren, Sparc kernel list,
linux-riscv, Jonas Bonn, linux-s390, Yoshinori Sato,
linux-hexagon, Huacai Chen, Russell King, linux-csky, Ingo Molnar,
linux-snps-arc, linux-xtensa, Heiko Carstens, linux-um,
linux-m68k, openrisc, linux-arm-kernel, Richard Henderson,
linux-parisc, Linux Kernel list, Palmer Dabbelt, linux-alpha,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20210317015210.33641-1-wangkefeng.wang@huawei.com>
On Wed, Mar 17, 2021 at 4:51 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> v2:
> - Cleanup 'str' line suggested by Christophe and ACK
applied patch (5.12.0-rc3-00020-g1df27313f50a-dirty) over linus.git
and tested boot on a sparc64 virtual machine (ldom) - boots.
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Christoph Hellwig @ 2021-03-17 13:53 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Dongli Zhang, iommu, xen-devel, Claire Chang, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <20210317134204.GA315788@konrad-char-us-oracle-com.allregionaliads.osdevelopmeniad.oraclevcn.com>
On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> > - if (!io_tlb_alloc_size)
> > - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > - __func__, alloc_size, PAGE_SIZE);
>
> Shouldn't this be converted to:
> mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> if (...)
>
> Seems that it got lost in the search and replace?
Yes, I messed that up during the rebase. That being said it magically
gets fixed in the next patch..
^ permalink raw reply
* Re: [PATCH 12/14] swiotlb: move global variables into a new io_tlb_mem structure
From: Konrad Rzeszutek Wilk @ 2021-03-17 13:42 UTC (permalink / raw)
To: Christoph Hellwig
Cc: xen-devel, iommu, Dongli Zhang, Claire Chang, linuxppc-dev
In-Reply-To: <20210301074436.919889-13-hch@lst.de>
..snip..
> int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
> {
..snip..
> /*
> * Allocate and initialize the free list array. This array is used
> * to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
> - * between io_tlb_start and io_tlb_end.
> + * between mem->start and mem->end.
> */
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(int));
> - io_tlb_list = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_list)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(int));
> + mem->list = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->list)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(phys_addr_t));
> - io_tlb_orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_orig_addr)
> + alloc_size = PAGE_ALIGN(mem->nslabs * sizeof(phys_addr_t));
> + mem->orig_addr = memblock_alloc(alloc_size, PAGE_SIZE);
> + if (!mem->orig_addr)
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> - io_tlb_alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
> - if (!io_tlb_alloc_size)
> - panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> - __func__, alloc_size, PAGE_SIZE);
Shouldn't this be converted to:
mem->alloc_size = memblock_alloc(alloc_size, PAGE_SIZE);
if (...)
Seems that it got lost in the search and replace?
> -
> - for (i = 0; i < io_tlb_nslabs; i++) {
> - io_tlb_list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> - io_tlb_orig_addr[i] = INVALID_PHYS_ADDR;
> - io_tlb_alloc_size[i] = 0;
> + for (i = 0; i < mem->nslabs; i++) {
> + mem->list[i] = IO_TLB_SEGSIZE - io_tlb_offset(i);
> + mem->orig_addr[i] = INVALID_PHYS_ADDR;
> + mem->alloc_size[i] = 0;
> }
> - io_tlb_index = 0;
> no_iotlb_memory = false;
>
> if (verbose)
> swiotlb_print_info();
>
> - swiotlb_set_max_segment(io_tlb_nslabs << IO_TLB_SHIFT);
> + swiotlb_set_max_segment(mem->nslabs << IO_TLB_SHIFT);
> return 0;
> }
>
..snip..
^ permalink raw reply
* [PATCH 1/2] ASoC: fsl-asoc-card: Add support for WM8958 codec
From: Shengjiu Wang @ 2021-03-17 13:05 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel, robh+dt,
devicetree
WM8958 codec is used on some i.MX based platform.
So add it support in this generic driver.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/Kconfig | 2 ++
sound/soc/fsl/fsl-asoc-card.c | 17 +++++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index c71c6024320b..0917d65d6921 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -310,6 +310,8 @@ config SND_SOC_FSL_ASOC_CARD
select SND_SOC_FSL_ESAI
select SND_SOC_FSL_SAI
select SND_SOC_FSL_SSI
+ select SND_SOC_WM8994
+ select MFD_WM8994
help
ALSA SoC Audio support with ASRC feature for Freescale SoCs that have
ESAI/SAI/SSI and connect with external CODECs such as WM8962, CS42888,
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index f62f81ceab0d..c62bfd1c3ac7 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -25,6 +25,7 @@
#include "../codecs/sgtl5000.h"
#include "../codecs/wm8962.h"
#include "../codecs/wm8960.h"
+#include "../codecs/wm8994.h"
#define CS427x_SYSCLK_MCLK 0
@@ -37,12 +38,14 @@
/**
* struct codec_priv - CODEC private data
* @mclk_freq: Clock rate of MCLK
+ * @free_freq: Clock rate of MCLK for hw_free()
* @mclk_id: MCLK (or main clock) id for set_sysclk()
* @fll_id: FLL (or secordary clock) id for set_sysclk()
* @pll_id: PLL id for set_pll()
*/
struct codec_priv {
unsigned long mclk_freq;
+ unsigned long free_freq;
u32 mclk_id;
u32 fll_id;
u32 pll_id;
@@ -235,10 +238,10 @@ static int fsl_asoc_card_hw_free(struct snd_pcm_substream *substream)
priv->streams &= ~BIT(substream->stream);
if (!priv->streams && codec_priv->pll_id && codec_priv->fll_id) {
- /* Force freq to be 0 to avoid error message in codec */
+ /* Force freq to be free_freq to avoid error message in codec */
ret = snd_soc_dai_set_sysclk(asoc_rtd_to_codec(rtd, 0),
codec_priv->mclk_id,
- 0,
+ codec_priv->free_freq,
SND_SOC_CLOCK_IN);
if (ret) {
dev_err(dev, "failed to switch away from FLL: %d\n", ret);
@@ -665,6 +668,15 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
priv->card.dapm_routes = audio_map_rx;
priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_rx);
+ } else if (of_device_is_compatible(np, "fsl,imx-audio-wm8958")) {
+ codec_dai_name = "wm8994-aif1";
+ priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
+ priv->codec_priv.mclk_id = WM8994_FLL_SRC_MCLK1;
+ priv->codec_priv.fll_id = WM8994_SYSCLK_FLL1;
+ priv->codec_priv.pll_id = WM8994_FLL1;
+ priv->codec_priv.free_freq = priv->codec_priv.mclk_freq;
+ priv->card.dapm_routes = NULL;
+ priv->card.num_dapm_routes = 0;
} else {
dev_err(&pdev->dev, "unknown Device Tree compatible\n");
ret = -EINVAL;
@@ -882,6 +894,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
{ .compatible = "fsl,imx-audio-mqs", },
{ .compatible = "fsl,imx-audio-wm8524", },
{ .compatible = "fsl,imx-audio-si476x", },
+ { .compatible = "fsl,imx-audio-wm8958", },
{}
};
MODULE_DEVICE_TABLE(of, fsl_asoc_card_dt_ids);
--
2.27.0
^ permalink raw reply related
* [PATCH 2/2] ASoC: bindings: fsl-asoc-card: add compatible string for WM8958 codec
From: Shengjiu Wang @ 2021-03-17 13:05 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel, robh+dt,
devicetree
In-Reply-To: <1615986303-27959-1-git-send-email-shengjiu.wang@nxp.com>
The WM8958 codec is used on i.MX7D val board.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 90d9e9d81624..23d83fa7609f 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -42,6 +42,8 @@ The compatible list for this generic sound card currently:
"fsl,imx-audio-si476x"
+ "fsl,imx-audio-wm8958"
+
Required properties:
- compatible : Contains one of entries in the compatible list.
--
2.27.0
^ permalink raw reply related
* Advice needed on SMP regression after cpu_core_mask change
From: Daniel Henrique Barboza @ 2021-03-17 13:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: aneesh.kumar, Srikar Dronamraju, Cedric Le Goater
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption made
in the commit:
"Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
equal on Power"
Doesn't seem to be true. After this commit, QEMU is now unable to set single NUMA
node SMP topologies such as:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
lscpu will give the following output in this case:
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-7
This is happening because the macro cpu_cpu_mask(cpu) expands to
cpumask_of_node(cpu_to_node(cpu)), which in turn expands to node_to_cpumask_map[node].
node_to_cpumask_map is a NUMA array that maps CPUs to NUMA nodes (Aneesh is on CC to
correct me if I'm wrong). We're now associating sockets to NUMA nodes directly.
If I add a second NUMA node then I can get the intended smp topology:
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s): 2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
However, if I try a single socket with multiple NUMA nodes topology, which is the case
of Power10, e.g.:
-smp 8,maxcpus=8,cores=4,threads=2,sockets=1
-numa node,memdev=mem0,cpus=0-3,nodeid=0 \
-numa node,memdev=mem1,cpus=4-7,nodeid=1 \
This is the result:
# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 2
NUMA node(s): 2
Model: 2.2 (pvr 004e 1202)
Model name: POWER9 (architected), altivec supported
Hypervisor vendor: KVM
Virtualization type: para
L1d cache: 32K
L1i cache: 32K
NUMA node0 CPU(s): 0-3
NUMA node1 CPU(s): 4-7
This confirms my suspicions that, at this moment, we're making sockets == NUMA nodes.
Cedric, the reason I'm CCing you is because this is related to ibm,chip-id. The commit
after the one that caused the regression, 4ca234a9cbd7c3a65 ("powerpc/smp: Stop updating
cpu_core_mask"), is erasing the code that calculated cpu_core_mask. cpu_core_mask, despite
its shortcomings that caused its removal, was giving a precise SMP topology. And it was
using physical_package_id/'ibm,chip-id' for that.
Checking in QEMU I can say that the ibm,chip-id calculation is the only place in the code
that cares about cores per socket information. The kernel is now ignoring that, starting
on 4bce545903fa, and now QEMU is unable to provide this info to the guest.
If we're not going to use ibm,chip-id any longer, which seems sensible given that PAPR does
not declare it, we need another way of letting the guest know how much cores per socket
we want.
[1] https://bugzilla.redhat.com/1934421
Thanks,
DHB
^ permalink raw reply
* Re: [PATCH v2] rpadlpar: fix potential drc_name corruption in store functions
From: Michael Ellerman @ 2021-03-17 12:23 UTC (permalink / raw)
To: Tyrel Datwyler, bhelgaas; +Cc: linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <20210315214821.452959-1-tyreld@linux.ibm.com>
On Mon, 15 Mar 2021 15:48:21 -0600, Tyrel Datwyler wrote:
> Both add_slot_store() and remove_slot_store() try to fix up the drc_name
> copied from the store buffer by placing a NULL terminator at nbyte + 1
> or in place of a '\n' if present. However, the static buffer that we
> copy the drc_name data into is not zeored and can contain anything past
> the n-th byte. This is problematic if a '\n' byte appears in that buffer
> after nbytes and the string copied into the store buffer was not NULL
> terminated to start with as the strchr() search for a '\n' byte will mark
> this incorrectly as the end of the drc_name string resulting in a drc_name
> string that contains garbage data after the n-th byte. The following
> debugging shows an example of the drmgr utility writing "PHB 4543" to
> the add_slot sysfs attribute, but add_slot_store logging a corrupted
> string value.
>
> [...]
Applied to powerpc/fixes.
[1/1] rpadlpar: fix potential drc_name corruption in store functions
https://git.kernel.org/powerpc/c/cc7a0bb058b85ea03db87169c60c7cfdd5d34678
cheers
^ 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