* Re: [PATCH] selftests: timens: Fix gettime_perf to work on powerpc
From: Michael Ellerman @ 2021-04-21 13:08 UTC (permalink / raw)
To: Shuah Khan, Christophe Leroy, Andrei Vagin, Dmitry Safonov
Cc: linuxppc-dev, linux-kernel, linux-kselftest
In-Reply-To: <469f37ab91984309eb68c0fb47e8438cdf5b6463.1617198956.git.christophe.leroy@csgroup.eu>
On Wed, 31 Mar 2021 13:59:17 +0000 (UTC), Christophe Leroy wrote:
> On powerpc:
> - VDSO library is named linux-vdso32.so.1 or linux-vdso64.so.1
> - clock_gettime is named __kernel_clock_gettime()
>
> Ensure gettime_perf tries these names before giving up.
Applied to powerpc/next.
[1/1] selftests: timens: Fix gettime_perf to work on powerpc
https://git.kernel.org/powerpc/c/f56607e85ee38f2a5bb7096e24e2d40f35d714f9
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32: Use r2 in wrtspr() instead of r0
From: Michael Ellerman @ 2021-04-21 13:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <69f9968f4b592fefda55227f0f7430ea612cc950.1611299687.git.christophe.leroy@csgroup.eu>
On Fri, 22 Jan 2021 07:15:03 +0000 (UTC), Christophe Leroy wrote:
> wrtspr() is a function to write an arbitrary value in a special
> register. It is used on 8xx to write to SPRN_NRI, SPRN_EID and
> SPRN_EIE. Writing any value to one of those will play with MSR EE
> and MSR RI regardless of that value.
>
> r0 is used many places in the generated code and using r0 for
> that creates an unnecessary dependency of this instruction with
> preceding ones using r0 in a few places in vmlinux.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32: Use r2 in wrtspr() instead of r0
https://git.kernel.org/powerpc/c/867e762480f4ad4106b16299a373fa23eccf5b4b
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/ebpf32: Fix comment on BPF_ALU{64} | BPF_LSH | BPF_K
From: Michael Ellerman @ 2021-04-21 13:08 UTC (permalink / raw)
To: naveen.n.rao, sandipan, yhs, Paul Mackerras, john.fastabend,
andrii, daniel, Christophe Leroy, kafai, songliubraving,
Benjamin Herrenschmidt, kpsingh, Michael Ellerman, ast
Cc: netdev, bpf, linuxppc-dev, linux-kernel
In-Reply-To: <34d12a4f75cb8b53a925fada5e7ddddd3b145203.1618227846.git.christophe.leroy@csgroup.eu>
On Mon, 12 Apr 2021 11:44:16 +0000 (UTC), Christophe Leroy wrote:
> Replace <<== by <<=
Applied to powerpc/next.
[1/3] powerpc/ebpf32: Fix comment on BPF_ALU{64} | BPF_LSH | BPF_K
https://git.kernel.org/powerpc/c/d228cc4969663623e6b5a749b02e4619352a0a8d
[2/3] powerpc/ebpf32: Rework 64 bits shifts to avoid tests and branches
https://git.kernel.org/powerpc/c/e7de0023e1232f42a10ef6af03352538cc27eaf6
[3/3] powerpc/ebpf32: Use standard function call for functions within 32M distance
https://git.kernel.org/powerpc/c/ee7c3ec3b4b1222b30272624897826bc40d79bc5
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/8xx: Enhance readability of trap types
From: Michael Ellerman @ 2021-04-21 13:08 UTC (permalink / raw)
To: sxwjean, Paul Mackerras, Christophe Leroy, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e1147287bf6f2fb0693048fe8db0298c7870e419.1618847273.git.christophe.leroy@csgroup.eu>
On Mon, 19 Apr 2021 15:48:09 +0000 (UTC), Christophe Leroy wrote:
> This patch makes use of trap types in head_8xx.S
Applied to powerpc/next.
[1/3] powerpc/8xx: Enhance readability of trap types
https://git.kernel.org/powerpc/c/0f5eb28a6ce6ab0882010e6727bfd6e8cd569273
[2/3] powerpc/32s: Enhance readability of trap types
https://git.kernel.org/powerpc/c/7fab639729ce4a0ecb3c528cd68b0c0598696ef9
[3/3] powerpc/irq: Enhance readability of trap types
https://git.kernel.org/powerpc/c/e522331173ec9af563461e0fae534e83ce39e8e3
cheers
^ permalink raw reply
* Re: [PATCH V2 0/5] powerpc/perf: Export processor pipeline stage cycles information
From: Michael Ellerman @ 2021-04-21 13:08 UTC (permalink / raw)
To: Athira Rajeev, acme, linux-kernel, linuxppc-dev, jolsa, mpe,
linux-perf-users
Cc: peterz, ravi.bangoria, kan.liang, maddy, kjain
In-Reply-To: <1616425047-1666-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Mon, 22 Mar 2021 10:57:22 -0400, Athira Rajeev wrote:
> Performance Monitoring Unit (PMU) registers in powerpc exports
> number of cycles elapsed between different stages in the pipeline.
> Example, sampling registers in ISA v3.1.
>
> This patchset implements kernel and perf tools support to expose
> these pipeline stage cycles using the sample type PERF_SAMPLE_WEIGHT_TYPE.
>
> [...]
Patch 1 applied to powerpc/next.
[1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
https://git.kernel.org/powerpc/c/af31fd0c9107e400a8eb89d0eafb40bb78802f79
cheers
^ permalink raw reply
* [PATCH 1/2] powerpc/fadump: Fix sparse warnings
From: Michael Ellerman @ 2021-04-21 12:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: hbathini
Sparse says:
arch/powerpc/kernel/fadump.c:48:16: warning: symbol 'fadump_kobj' was not declared. Should it be static?
arch/powerpc/kernel/fadump.c:55:27: warning: symbol 'crash_mrange_info' was not declared. Should it be static?
arch/powerpc/kernel/fadump.c:61:27: warning: symbol 'reserved_mrange_info' was not declared. Should it be static?
arch/powerpc/kernel/fadump.c:83:12: warning: symbol 'fadump_cma_init' was not declared. Should it be static?
And indeed none of them are used outside this file, they can all be made
static. Also fadump_kobj needs to be moved inside the ifdef where it's
used.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/fadump.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 000e3b7f3fca..b990075285f5 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -45,22 +45,21 @@ static struct fw_dump fw_dump;
static void __init fadump_reserve_crash_area(u64 base);
-struct kobject *fadump_kobj;
-
#ifndef CONFIG_PRESERVE_FA_DUMP
+static struct kobject *fadump_kobj;
+
static atomic_t cpus_in_fadump;
static DEFINE_MUTEX(fadump_mutex);
-struct fadump_mrange_info crash_mrange_info = { "crash", NULL, 0, 0, 0, false };
+static struct fadump_mrange_info crash_mrange_info = { "crash", NULL, 0, 0, 0, false };
#define RESERVED_RNGS_SZ 16384 /* 16K - 128 entries */
#define RESERVED_RNGS_CNT (RESERVED_RNGS_SZ / \
sizeof(struct fadump_memory_range))
static struct fadump_memory_range rngs[RESERVED_RNGS_CNT];
-struct fadump_mrange_info reserved_mrange_info = { "reserved", rngs,
- RESERVED_RNGS_SZ, 0,
- RESERVED_RNGS_CNT, true };
+static struct fadump_mrange_info
+reserved_mrange_info = { "reserved", rngs, RESERVED_RNGS_SZ, 0, RESERVED_RNGS_CNT, true };
static void __init early_init_dt_scan_reserved_ranges(unsigned long node);
@@ -80,7 +79,7 @@ static struct cma *fadump_cma;
* But for some reason even if it fails we still have the memory reservation
* with us and we can still continue doing fadump.
*/
-int __init fadump_cma_init(void)
+static int __init fadump_cma_init(void)
{
unsigned long long base, size;
int rc;
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/powernv: Fix type of opal_mpipl_query_tag() addr argument
From: Michael Ellerman @ 2021-04-21 12:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: hbathini
In-Reply-To: <20210421125402.1955013-1-mpe@ellerman.id.au>
opal_mpipl_query_tag() takes a pointer to a 64-bit value, which firmware
writes a value to. As OPAL is traditionally big endian this value will
be big endian.
This can be confirmed by looking at the implementation in skiboot:
static uint64_t opal_mpipl_query_tag(enum opal_mpipl_tags tag, __be64 *tag_val)
{
...
*tag_val = cpu_to_be64(opal_mpipl_tags[tag]);
return OPAL_SUCCESS;
}
Fix the declaration to annotate that the value is big endian.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/opal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9986ac34b8e2..c76157237e22 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -307,7 +307,7 @@ int opal_secvar_enqueue_update(const char *key, uint64_t key_len, u8 *data,
s64 opal_mpipl_update(enum opal_mpipl_ops op, u64 src, u64 dest, u64 size);
s64 opal_mpipl_register_tag(enum opal_mpipl_tags tag, u64 addr);
-s64 opal_mpipl_query_tag(enum opal_mpipl_tags tag, u64 *addr);
+s64 opal_mpipl_query_tag(enum opal_mpipl_tags tag, __be64 *addr);
s64 opal_signal_system_reset(s32 cpu);
s64 opal_quiesce(u64 shutdown_type, s32 cpu);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v11 6/6] powerpc: Book3S 64-bit outline-only KASAN support
From: Christophe Leroy @ 2021-04-21 12:29 UTC (permalink / raw)
To: Daniel Axtens, linux-kernel, linux-mm, linuxppc-dev, kasan-dev,
aneesh.kumar, bsingharora
In-Reply-To: <20210319144058.772525-7-dja@axtens.net>
Le 19/03/2021 à 15:40, Daniel Axtens a écrit :
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index aca354fb670b..63672aa656e8 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -20,6 +20,7 @@
> #include <linux/seq_file.h>
> #include <asm/fixmap.h>
> #include <linux/const.h>
> +#include <linux/kasan.h>
> #include <asm/page.h>
> #include <asm/hugetlb.h>
>
> @@ -317,6 +318,23 @@ static void walk_pud(struct pg_state *st, p4d_t *p4d, unsigned long start)
> unsigned long addr;
> unsigned int i;
>
> +#if defined(CONFIG_KASAN) && defined(CONFIG_PPC_BOOK3S_64)
> + /*
> + * On radix + KASAN, we want to check for the KASAN "early" shadow
> + * which covers huge quantities of memory with the same set of
> + * read-only PTEs. If it is, we want to note the first page (to see
> + * the status change), and then note the last page. This gives us good
> + * results without spending ages noting the exact same PTEs over 100s of
> + * terabytes of memory.
> + */
> + if (p4d_page(*p4d) == virt_to_page(lm_alias(kasan_early_shadow_pud))) {
> + walk_pmd(st, pud, start);
> + addr = start + (PTRS_PER_PUD - 1) * PUD_SIZE;
> + walk_pmd(st, pud, addr);
> + return;
> + }
> +#endif
> +
> for (i = 0; i < PTRS_PER_PUD; i++, pud++) {
> addr = start + i * PUD_SIZE;
> if (!pud_none(*pud) && !pud_is_leaf(*pud))
The above changes should not be necessary once PPC_PTDUMP is converted to GENERIC_PTDUMP.
See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=239795
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Add load address to plt branch targets before moved to linked location for non-relocatable kernels
From: Christophe Leroy @ 2021-04-21 11:59 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20210421021721.1539289-1-jniethe5@gmail.com>
Le 21/04/2021 à 04:17, Jordan Niethe a écrit :
> Large branches will go through the plt which includes a stub that loads
> a target address from the .branch_lt section. On a relocatable kernel the
> targets in .branch_lt have relocations so they will be fixed up for
> where the kernel is running by relocate().
>
> For a non-relocatable kernel obviously there are no relocations.
> However, until the kernel is moved down to its linked address it is
> expected to be able to run where ever it is loaded. For pseries machines
> prom_init() is called before running at the linked address.
>
> Certain configs result in a large kernel such as STRICT_KERNEL_RWX
> (because of the larger data shift):
>
> config DATA_SHIFT
> int "Data shift" if DATA_SHIFT_BOOL
> default 24 if STRICT_KERNEL_RWX && PPC64
>
> These large kernels lead to prom_init()'s final call to __start()
> generating a plt branch:
>
> bl c000000002000018 <00000078.plt_branch.__start>
>
> This results in the kernel jumping to the linked address of __start,
> 0xc000000000000000, when really it needs to jump to the
> 0xc000000000000000 + the runtime address because the kernel is still
> running at the load address.
On ppc32 it seems to be different. I can't find plt_branch or lt_branch or whatever.
Looks like the stubs are placed at the end of .head section, and just after prom_init:
c0003858 <setup_disp_bat>:
c0003858: 7d 08 02 a6 mflr r8
c000385c: 48 00 d5 35 bl c0010d90 <reloc_offset>
c0003860: 7d 08 03 a6 mtlr r8
c0003864: 3d 03 c2 04 addis r8,r3,-15868
c0003868: 39 08 1d 08 addi r8,r8,7432
c000386c: 2c 08 00 00 cmpwi r8,0
c0003870: 4d 82 00 20 beqlr
c0003874: 81 68 00 00 lwz r11,0(r8)
c0003878: 81 08 00 04 lwz r8,4(r8)
c000387c: 7d 1f 83 a6 mtdbatl 3,r8
c0003880: 7d 7e 83 a6 mtdbatu 3,r11
c0003884: 4e 80 00 20 blr
c0003888: 3d 80 c2 00 lis r12,-15872
c000388c: 39 8c 16 dc addi r12,r12,5852
c0003890: 7d 89 03 a6 mtctr r12
c0003894: 4e 80 04 20 bctr
c0003898: 3d 80 c2 01 lis r12,-15871
c000389c: 39 8c e1 38 addi r12,r12,-7880
c00038a0: 7d 89 03 a6 mtctr r12
c00038a4: 4e 80 04 20 bctr
c00038a8: 3d 80 c2 00 lis r12,-15872
c00038ac: 39 8c 74 d0 addi r12,r12,29904
c00038b0: 7d 89 03 a6 mtctr r12
c00038b4: 4e 80 04 20 bctr
c00038b8: 3d 80 c2 00 lis r12,-15872
c00038bc: 39 8c 73 38 addi r12,r12,29496
c00038c0: 7d 89 03 a6 mtctr r12
c00038c4: 4e 80 04 20 bctr
c00038c8: 3d 80 c2 01 lis r12,-15871
c00038cc: 39 8c 83 6c addi r12,r12,-31892
c00038d0: 7d 89 03 a6 mtctr r12
c00038d4: 4e 80 04 20 bctr
c00038d8: 3d 80 c2 01 lis r12,-15871
c00038dc: 39 8c 8f 08 addi r12,r12,-28920
c00038e0: 7d 89 03 a6 mtctr r12
c00038e4: 4e 80 04 20 bctr
Disassembly of section .text:
c0004000 <Reset_virt>:
c20016dc <prom_init>:
c20016dc: 94 21 ff 50 stwu r1,-176(r1)
c20016e0: 7c 08 02 a6 mflr r0
c20016e4: 42 9f 00 05 bcl 20,4*cr7+so,c20016e8 <prom_init+0xc>
c20016e8: bd c1 00 68 stmw r14,104(r1)
c20016ec: 7f c8 02 a6 mflr r30
c20016f0: 90 01 00 b4 stw r0,180(r1)
c20016f4: 7c bb 2b 78 mr r27,r5
c20016f8: 80 1e ff f0 lwz r0,-16(r30)
....
c20026d4: 4a 00 ed 69 bl c001143c <reloc_got2>
c20026d8: 7f e3 fb 78 mr r3,r31
c20026dc: 7f 24 cb 78 mr r4,r25
c20026e0: 39 20 00 00 li r9,0
c20026e4: 39 00 00 00 li r8,0
c20026e8: 38 e0 00 00 li r7,0
c20026ec: 38 c0 00 00 li r6,0
c20026f0: 38 a0 00 00 li r5,0
c20026f4: 48 00 00 61 bl c2002754 <prom_init+0x1078>
c20026f8: 38 60 00 00 li r3,0
c20026fc: 80 01 00 b4 lwz r0,180(r1)
c2002700: 81 c1 00 68 lwz r14,104(r1)
c2002704: 81 e1 00 6c lwz r15,108(r1)
c2002708: 7c 08 03 a6 mtlr r0
c200270c: 82 01 00 70 lwz r16,112(r1)
c2002710: 82 21 00 74 lwz r17,116(r1)
c2002714: 82 41 00 78 lwz r18,120(r1)
c2002718: 82 61 00 7c lwz r19,124(r1)
c200271c: 82 81 00 80 lwz r20,128(r1)
c2002720: 82 a1 00 84 lwz r21,132(r1)
c2002724: 82 c1 00 88 lwz r22,136(r1)
c2002728: 82 e1 00 8c lwz r23,140(r1)
c200272c: 83 01 00 90 lwz r24,144(r1)
c2002730: 83 21 00 94 lwz r25,148(r1)
c2002734: 83 41 00 98 lwz r26,152(r1)
c2002738: 83 61 00 9c lwz r27,156(r1)
c200273c: 83 81 00 a0 lwz r28,160(r1)
c2002740: 83 a1 00 a4 lwz r29,164(r1)
c2002744: 83 c1 00 a8 lwz r30,168(r1)
c2002748: 83 e1 00 ac lwz r31,172(r1)
c200274c: 38 21 00 b0 addi r1,r1,176
c2002750: 4e 80 00 20 blr
c2002754: 3d 80 c0 00 lis r12,-16384
c2002758: 39 8c 00 0c addi r12,r12,12
c200275c: 7d 89 03 a6 mtctr r12
c2002760: 4e 80 04 20 bctr
Any idea on how the GNU ld does it and how we can alter it, or force generation of dedicated section
like on PPC64 ?
Christophe
^ permalink raw reply
* [PATCH v2] soc: fsl: qe: Remove unused function
From: Jiapeng Chong @ 2021-04-21 10:56 UTC (permalink / raw)
To: qiang.zhao
Cc: Jiapeng Chong, linuxppc-dev, linux-kernel, linux-arm-kernel,
leoyang.li
The last callers of this function were removed by commit d7c2878cfcfa
("soc: fsl: qe: remove unused qe_ic_set_* functions"):
https://github.com/torvalds/linux/commit/d7c2878cfcfa
Fix the following clang warning:
drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
'qe_ic_from_irq' [-Wunused-function].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
---
Changes in v2:
- Modified submission information.
drivers/soc/fsl/qe/qe_ic.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 0390af9..b573712 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32 __iomem *base, unsigned int reg,
qe_iowrite32be(value, base + (reg >> 2));
}
-static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
-{
- return irq_get_chip_data(virq);
-}
-
static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
{
return irq_data_get_irq_chip_data(d);
--
1.8.3.1
^ permalink raw reply related
* Re: powerpc{32,64} randconfigs
From: Masahiro Yamada @ 2021-04-21 10:08 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Randy Dunlap, PowerPC, linux-kbuild
In-Reply-To: <87tuo0az16.fsf@mpe.ellerman.id.au>
On Wed, Apr 21, 2021 at 4:15 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Randy Dunlap <rdunlap@infradead.org> writes:
> > Hi,
> >
> > Is there a way to do this?
> >
> > $ make ARCH=powerpc randconfig # and force PPC32
>
> Sort of:
>
> $ KCONFIG_ALLCONFIG=arch/powerpc/configs/book3s_32.config make randconfig
>
> But that also forces BOOK3S.
>
> > and separately
> > $ make ARCH=powerpc randconfig # and force PPC64
>
> No.
>
> ...
> > OK, I have a patch that seems for work as far as setting
> > PPC32=y or PPC64=y... but it has a problem during linking
> > of vmlinux:
> >
> > crosstool/gcc-9.3.0-nolibc/powerpc-linux/bin/powerpc-linux-ld:./arch/powerpc/kernel/vmlinux.lds:6: syntax error
> >
> > and the (bad) generated vmlinux.lds file says (at line 6):
> >
> > OUTPUT_ARCH(1:common)
> >
> > while it should say:
> >
> > OUTPUT_ARCH(powerpc:common)
> >
> > Does anyone have any ideas about this problem?
>
> I guess your patch broke something? :D
> Not sure sorry.
>
> What about something like this?
>
> cheers
>
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 3212d076ac6a..712c5e8768ce 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -376,6 +376,16 @@ PHONY += ppc64_book3e_allmodconfig
> $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
> -f $(srctree)/Makefile allmodconfig
>
> +PHONY += ppc32_randconfig
> +ppc32_randconfig:
> + $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \
> + -f $(srctree)/Makefile randconfig
> +
> +PHONY += ppc64_randconfig
> +ppc64_randconfig:
> + $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \
> + -f $(srctree)/Makefile randconfig
> +
> define archhelp
> @echo '* zImage - Build default images selected by kernel config'
> @echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
> diff --git a/arch/powerpc/configs/32-bit.config b/arch/powerpc/configs/32-bit.config
> new file mode 100644
> index 000000000000..bdf833009006
> --- /dev/null
> +++ b/arch/powerpc/configs/32-bit.config
> @@ -0,0 +1 @@
> +CONFIG_PPC64=n
Please do:
# CONFIG_PPC64 is not set
> diff --git a/arch/powerpc/configs/64-bit.config b/arch/powerpc/configs/64-bit.config
> new file mode 100644
> index 000000000000..0fe6406929e2
> --- /dev/null
> +++ b/arch/powerpc/configs/64-bit.config
> @@ -0,0 +1 @@
> +CONFIG_PPC64=y
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Add load address to plt branch targets before moved to linked location for non-relocatable kernels
From: Christophe Leroy @ 2021-04-21 9:01 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20210421021721.1539289-1-jniethe5@gmail.com>
Le 21/04/2021 à 04:17, Jordan Niethe a écrit :
> Large branches will go through the plt which includes a stub that loads
> a target address from the .branch_lt section. On a relocatable kernel the
> targets in .branch_lt have relocations so they will be fixed up for
> where the kernel is running by relocate().
>
> For a non-relocatable kernel obviously there are no relocations.
> However, until the kernel is moved down to its linked address it is
> expected to be able to run where ever it is loaded. For pseries machines
> prom_init() is called before running at the linked address.
>
> Certain configs result in a large kernel such as STRICT_KERNEL_RWX
> (because of the larger data shift):
Same problem occurs on 32s, see discussion at https://bugzilla.kernel.org/show_bug.cgi?id=208181#c14
>
> config DATA_SHIFT
> int "Data shift" if DATA_SHIFT_BOOL
> default 24 if STRICT_KERNEL_RWX && PPC64
>
> These large kernels lead to prom_init()'s final call to __start()
> generating a plt branch:
>
> bl c000000002000018 <00000078.plt_branch.__start>
>
> This results in the kernel jumping to the linked address of __start,
> 0xc000000000000000, when really it needs to jump to the
> 0xc000000000000000 + the runtime address because the kernel is still
> running at the load address.
>
> The first 256 bytes are already copied to address 0 so the kernel will
> run until
>
> b __start_initialization_multiplatform
>
> because there is nothing yet at __start_initialization_multiplatform
> this will inevitably crash. At this point the exception handlers are
> still OF's.
>
> On phyp this will look like:
>
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 5.12.0-rc3-63029-gada7d7e600c0 (gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1), GNU ld version 2.30-93.el8) #1 SMP Wed Apr 7 07:24:20 EDT 2021
> Detected machine type: 0000000000000101
> command line: BOOT_IMAGE=/vmlinuz-5.12.0-rc3-63029-gada7d7e600c0
> Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
> Calling ibm,client-architecture-support... done
> memory layout at init:
> memory_limit : 0000000000000000 (16 MB aligned)
> alloc_bottom : 000000000edc0000
> alloc_top : 0000000020000000
> alloc_top_hi : 0000000020000000
> rmo_top : 0000000020000000
> ram_top : 0000000020000000
> instantiating rtas at 0x000000001ec30000... done
> prom_hold_cpus: skipped
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x000000000edd0000 -> 0x000000000edd1809
> Device tree struct 0x000000000ede0000 -> 0x000000000edf0000
> Quiescing Open Firmware ...
> Booting Linux via __start() @ 0x000000000a710000 ...
> DEFAULT CATCH!, exception-handler=fffffffffffffff6
> at %SRR0: 0000000000000f20 %SRR1: 8000000000081000
> Open Firmware exception handler entered from non-OF code
> Client's Fix Pt Regs:
> 00 000000000c713134 0000000008a9fc00 000000000caf9c00 000000000edc0000
> 04 000000000a710000 0000000000000000 0000000000000000 0000000000000000
> 08 0000000000000000 0000000000000000 000000000a7200fc 0000000000003003
> 0c c000000000000000 0000000000000000 0000000000000000 000000000b5a9820
> 10 000000000b5a9b38 000000000b5a9988 000000000b5a9f38 000000000b660c10
> 14 000000000b5a9f60 00000000013d0000 000000001ec30000 000000001ec30000
> 18 000000000b5a9840 000000000a710000 0000000000000028 000000000edc0008
> 1c 000000000edc0000 000000000cb60000 0000000000000000 000000000edc0000
> Special Regs:
> %IV: 00000700 %CR: 44000202 %XER: 00000000 %DSISR: 00000000
> %SRR0: 0000000000000f20 %SRR1: 8000000000081000
> %LR: 000000000c71326c %CTR: c000000000000000
> %DAR: 0000000000000000
> Virtual PID = 0
> DEFAULT CATCH!, throw-code=fffffffffffffff6
> Call History
> ------------
> throw - c3f05c
> $call-method - c4f0b4
> (poplocals) - c40a00
> key-fillq - c4f4cc
> ?xoff - c4f5b4
> (poplocals) - c40a00
> (stdout-write) - c4fa64
> (emit) - c4fb3c
> space - c4dfc8
> quit - c5336c
> quit - c53100
> My Fix Pt Regs:
> 00 800000000000b002 0000000000000000 00000000deadbeef 0000000000c4f0b0
> 04 0000000008bfff80 00000000deadbeef 0000000000000004 0000000000c09010
> 08 0000000000000005 0000000000000000 0000000000000000 0000000000000000
> 0c 80000000072a40a8 0000000000000000 0000000000000000 0000000008d2cf30
> 10 0000000000e7d968 0000000000e7d968 0000000000c4f0a8 0000000000c4f0b4
> 14 fffffffffffffff6 0000000008bfff80 c8ff21fbd0ff41fb f8ffe1fbb1fd21f8
> 18 0000000000c19000 0000000000c3e000 0000000000c1af80 0000000000c1cfc0
> 1c 0000000000c26000 0000000000c460f0 0000000000c17fa8 0000000000c16fe0
> Special Regs:
> %IV: 00000900 %CR: 84800208 %XER: 00040010 %DSISR: 00000000
> %SRR0: 0000000000c3eec8 %SRR1: 800000000000b002
> %LR: 0000000000c3f05c %CTR: 0000000000c4f0b0
> %DAR: 0000000000000000
> ...
>
> On qemu it will just appear to be stuck after
> Booting Linux via __start() @ 0x0000000000400000 ...:
>
> SLOF **********************************************************************
> QEMU Starting
> Build Date = Apr 9 2021 14:13:31
> FW Version = git-33a7322de13e9dca
> Press "s" to enter Open Firmware.
>
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/l-lan@71000002
> Populating /vdevice/v-scsi@71000003
> SCSI: Looking for devices
> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
> Populating /pci@800000020000000
> Scanning USB
> Using default console: /vdevice/vty@71000000
> Detected RAM kernel at 400000 (25baa08 bytes)
>
> Welcome to Open Firmware
>
> Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
> This program and the accompanying materials are made available
> under the terms of the BSD License available at
> http://www.opensource.org/licenses/bsd-license.php
>
> Booting from memory...
> OF stdout device is: /vdevice/vty@71000000
> Preparing to boot Linux version 5.12.0-rc3-00128-g87a8d2180282 (powerpc64le-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #85 SMP Sun Apr 18 19:30:55 AEST 2021
> Detected machine type: 0000000000000101
> command line: nokaslr
> Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
> Calling ibm,client-architecture-support... done
> memory layout at init:
> memory_limit : 0000000000000000 (16 MB aligned)
> alloc_bottom : 0000000003df0000
> alloc_top : 0000000030000000
> alloc_top_hi : 0000000080000000
> rmo_top : 0000000030000000
> ram_top : 0000000080000000
> instantiating rtas at 0x000000002fff0000... done
> prom_hold_cpus: skipped
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000003e00000 -> 0x0000000003e00ab2
> Device tree struct 0x0000000003e10000 -> 0x0000000003e20000
> Quiescing Open Firmware ...
> Booting Linux via __start() @ 0x0000000000400000 ...
>
> To fix this do some "relocation" of the plt target addresses on
> non-relocatable before running at the linked address. Before calling
> prom_init() add the runtime address to all the targets in .branch_lt
> with relocate_plt(). Have relocate_plt() save the offset added in
> p_branch_lt_off. After prom_init() calls __start() remove the offset
> saved in p_branch_lt_off to return the targets to their original
> addresses.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> ---
> arch/powerpc/include/asm/sections.h | 2 +
> arch/powerpc/kernel/head_64.S | 66 +++++++++++++++++++++++++++++
> arch/powerpc/kernel/vmlinux.lds.S | 2 +
> 3 files changed, 70 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/sections.h b/arch/powerpc/include/asm/sections.h
> index 324d7b298ec3..f087f5cd5a50 100644
> --- a/arch/powerpc/include/asm/sections.h
> +++ b/arch/powerpc/include/asm/sections.h
> @@ -30,6 +30,8 @@ extern char __end_interrupts[];
>
> extern char __prom_init_toc_start[];
> extern char __prom_init_toc_end[];
> +extern char __branch_lt_start[];
> +extern char __branch_lt_end[];
>
> #ifdef CONFIG_PPC_POWERNV
> extern char start_real_trampolines[];
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index ece7f97bafff..28a6c2abd3ab 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -560,8 +560,11 @@ __boot_from_prom:
> /* Relocate code for where we are now */
> mr r3,r26
> bl relocate
> +#else
> + bl relocate_plt
> #endif
>
> +
> /* Restore parameters */
> mr r3,r31
> mr r4,r30
> @@ -600,6 +603,8 @@ __after_prom_start:
> /* IVPR needs to be set after relocation. */
> bl init_core_book3e
> #endif
> +#else
> + bl unrelocate_plt
> #endif
>
> /*
> @@ -901,6 +906,67 @@ _GLOBAL(relative_toc)
> .balign 8
> p_toc: .8byte __toc_start + 0x8000 - 0b
>
> +/*
> + * A large non relocatable kernel may generate branches that go though the plt,
> + * before the kernel is copied down to its link location, the target address in
> + * the .branch_lt section need to be offset with the run time address. The
> + * offset then needs to be removed before the kernel is running at the correct
> + * address. When relocate_plt is called the current runtime address is added
> + * to all of the target address in .branch_lt and that address is stored in
> + * p_branch_lt_off. When unrelocate_plt is called if there is an offset saved
> + * in p_branch_lt_off it is subtracted from the addresses in .branch_lt to
> + * return them to their original targets.
> + */
> +#ifndef CONFIG_RELOCATABLE
> +#define RELOCATE_MODE 0
> +#define UNRELOCATE_MODE 1
> +unrelocate_plt:
> + li r16,UNRELOCATE_MODE
> + b +8
> +relocate_plt:
> + li r16,RELOCATE_MODE
> + mflr r0
> + bcl 20,31,$+4
> +0: mflr r11
> +
> + ld r12,(p_branch_lt_start - 0b)(r11)
> + add r12,r12,r11
> + ld r14,(p_branch_lt_end - 0b)(r11)
> + add r14,r14,r11
> + ld r15,(p_branch_lt_off - 0b)(r11)
> +
> + /* Adding runtime address or subtracting p_branch_lt_off? */
> + cmpdi r16,UNRELOCATE_MODE
> + bne 5f
> + cmpdi r15,0
> + beq 4f
> + mr r10,r15
> + neg r10,r10
> + b 2f
> +5: mr r10,r26
> +
> + /* Iterate over all targets in .branch_lt */
> +2: cmpd r12,r14
> + bge 6f
> + ld r13,0(r12)
> + add r13,r13, r10
> + std r13,0(r12)
> + addi r12,r12, 8
> + b 2b
> +
> +6: cmpdi r16,RELOCATE_MODE
> + bne 4f
> + std r26,(p_branch_lt_off - 0b)(r11)
> +
> +4: mtlr r0
> + blr
> +
> +.balign 8
> +p_branch_lt_start: .8byte __branch_lt_start - 0b
> +p_branch_lt_end: .8byte __branch_lt_end - 0b
> +p_branch_lt_off: .8byte 0
> +#endif
> +
> /*
> * This is where the main kernel code starts.
> */
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index 72fa3c00229a..99085558ad3a 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -317,7 +317,9 @@ SECTIONS
> #endif
> *(.data.rel*)
> *(.toc1)
> + __branch_lt_start = .;
> *(.branch_lt)
> + __branch_lt_end = .;
> }
>
> .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
>
^ permalink raw reply
* Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
From: Arnd Bergmann @ 2021-04-21 8:58 UTC (permalink / raw)
To: David Laight
Cc: grygorii.strashko@ti.com, linux-snps-arc@lists.infradead.org,
netdev@vger.kernel.org, Vineet Gupta, ilias.apalodimas@linaro.org,
linux-kernel@vger.kernel.org, Matthew Wilcox,
linux-mips@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de,
brouer@redhat.com, mcroce@linux.microsoft.com, mhocko@kernel.org,
linuxppc-dev@lists.ozlabs.org, hch@lst.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5c41d562589b497ca3c1047e0e18b3a1@AcuMS.aculab.com>
On Wed, Apr 21, 2021 at 10:43 AM David Laight <David.Laight@aculab.com> wrote:
> From: Arnd Bergmann Sent: 20 April 2021 22:20
> > On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
> > > On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> >
> > > >
> > > > which means that half the 32-bit architectures do this. This may
> > > > cause more problems when arc and/or microblaze want to support
> > > > 64-bit kernels and compat mode in the future on their latest hardware,
> > > > as that means duplicating the x86 specific hacks we have for compat.
> > > >
> > > > What is alignof(u64) on 64-bit arc?
> > >
> > > $ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc -
> > > -Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
> > > 8
> >
> > Ok, good.
>
> That test doesn't prove anything.
> Try running on x86:
> $ echo 'int a = __alignof__(long long);' | gcc -xc - -Wall -S -o - -m32
> a:
> .long 8
Right, I had wondered about that one after I sent the email.
> Using '__alignof__(struct {long long x;})' does give the expected 4.
>
> __alignof__() returns the preferred alignment, not the enforced
> alignmnet - go figure.
I checked the others as well now, and i386 is the only one that
changed here: m68k still has '2', while arc/csky/h8300/microblaze/
nios2/or1k/sh/i386 all have '4' and the rest have '8'.
Arnd
^ permalink raw reply
* Re: mmu.c:undefined reference to `patch__hash_page_A0'
From: Christophe Leroy @ 2021-04-21 8:43 UTC (permalink / raw)
To: Randy Dunlap, kernel test robot; +Cc: PowerPC, kbuild-all, linux-kernel
In-Reply-To: <0a301d17-136c-df65-17cc-3c9ddbe06de8@infradead.org>
Le 18/04/2021 à 19:15, Randy Dunlap a écrit :
> On 4/18/21 3:43 AM, Christophe Leroy wrote:
>>
>>
>> Le 18/04/2021 à 02:02, Randy Dunlap a écrit :
>>> HI--
>>>
>>> I no longer see this build error.
>>
>> Fixed by https://github.com/torvalds/linux/commit/acdad8fb4a1574323db88f98a38b630691574e16
>>
>>> However:
>>>
>>> On 2/27/21 2:24 AM, kernel test robot wrote:
>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>>> head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
>>>> commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash code when CONFIG_PPC_BOOK3S_604 is selected
>>>> date: 4 weeks ago
>>>> config: powerpc64-randconfig-r013-20210227 (attached as .config)
>>>
>>> ktr/lkp, this is a PPC32 .config file that is attached, not PPC64.
>>>
>>> Also:
>>>
>>>> compiler: powerpc-linux-gcc (GCC) 9.3.0
>>
>> ...
>>
>>>
>>> I do see this build error:
>>>
>>> powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress':
>>> decompress.c:(.text+0x1f0): undefined reference to `__decompress'
>>>
>>> when either
>>> CONFIG_KERNEL_LZO=y
>>> or
>>> CONFIG_KERNEL_LZMA=y
>>>
>>> but the build succeeds when either
>>> CONFIG_KERNEL_GZIP=y
>>> or
>>> CONFIG_KERNEL_XZ=y
>>>
>>> I guess that is due to arch/powerpc/boot/decompress.c doing this:
>>>
>>> #ifdef CONFIG_KERNEL_GZIP
>>> # include "decompress_inflate.c"
>>> #endif
>>>
>>> #ifdef CONFIG_KERNEL_XZ
>>> # include "xz_config.h"
>>> # include "../../../lib/decompress_unxz.c"
>>> #endif
>>>
>>>
>>> It would be nice to require one of KERNEL_GZIP or KERNEL_XZ
>>> to be set/enabled (maybe unless a uImage is being built?).
>>
>>
>> Can you test by https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a74fce4dfc9fa32da6ce3470bbedcecf795de1ec.1591189069.git.christophe.leroy@csgroup.eu/ ?
>
> Hi Christophe,
>
> I get build errors for both LZO and LZMA:
>
Can you check with the following changes on top of my patch:
diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index a8dbde4b32d4..f06f925385c0 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -23,13 +23,15 @@
#include <linux/decompress/unlzo.h>
#endif
-#include <linux/lzo.h>
#ifdef __KERNEL__
#include <linux/types.h>
+#endif
+#include <linux/lzo.h>
+#ifdef __KERNEL__
#include <linux/decompress/mm.h>
+#include <linux/compiler.h>
#endif
-#include <linux/compiler.h>
#include <asm/unaligned.h>
static const unsigned char lzop_magic[] = {
Thanks
Christophe
^ permalink raw reply related
* RE: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
From: David Laight @ 2021-04-21 8:43 UTC (permalink / raw)
To: 'Arnd Bergmann', Vineet Gupta
Cc: grygorii.strashko@ti.com, linux-snps-arc@lists.infradead.org,
netdev@vger.kernel.org, ilias.apalodimas@linaro.org,
linux-kernel@vger.kernel.org, Matthew Wilcox,
linux-mips@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de,
brouer@redhat.com, mcroce@linux.microsoft.com, mhocko@kernel.org,
linuxppc-dev@lists.ozlabs.org, hch@lst.de,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
From: Arnd Bergmann
> Sent: 20 April 2021 22:20
>
> On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
> > On 4/20/21 12:07 AM, Arnd Bergmann wrote:
>
> > >
> > > which means that half the 32-bit architectures do this. This may
> > > cause more problems when arc and/or microblaze want to support
> > > 64-bit kernels and compat mode in the future on their latest hardware,
> > > as that means duplicating the x86 specific hacks we have for compat.
> > >
> > > What is alignof(u64) on 64-bit arc?
> >
> > $ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc -
> > -Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
> > 8
>
> Ok, good.
That test doesn't prove anything.
Try running on x86:
$ echo 'int a = __alignof__(long long);' | gcc -xc - -Wall -S -o - -m32
.file ""
.globl a
.data
.align 4
.type a, @object
.size a, 4
a:
.long 8
.ident "GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609"
.section .note.GNU-stack,"",@progbits
Using '__alignof__(struct {long long x;})' does give the expected 4.
__alignof__() returns the preferred alignment, not the enforced
alignmnet - go figure.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] soc: fsl: qe: remove unused function
From: Jiapeng Chong @ 2021-04-21 7:56 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <76468b5b-0eb0-8772-b7b5-21bb708aa053@csgroup.eu>
On 2021/4/16 15:06, Christophe Leroy wrote:
>
>
> Le 16/04/2021 à 08:57, Daniel Axtens a écrit :
>> Hi Jiapeng,
>>
>>> Fix the following clang warning:
>
> You are not fixing a warning, you are removing a function in order to
> fix a warning ...
>
>>>
>>> drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
>>> 'qe_ic_from_irq' [-Wunused-function].
>
> Would be wise to tell that the last users of the function where removed
> by commit d7c2878cfcfa ("soc: fsl: qe: remove unused qe_ic_set_*
> functions")
>
> https://github.com/torvalds/linux/commit/d7c2878cfcfa
>
>>>
>>> Reported-by: Abaci Robot <abaci@linux.alibaba.com>
>>> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
>>> ---
>>> drivers/soc/fsl/qe/qe_ic.c | 5 -----
>>> 1 file changed, 5 deletions(-)
>>>
>>> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
>>> index 0390af9..b573712 100644
>>> --- a/drivers/soc/fsl/qe/qe_ic.c
>>> +++ b/drivers/soc/fsl/qe/qe_ic.c
>>> @@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32 __iomem
>>> *base, unsigned int reg,
>>> qe_iowrite32be(value, base + (reg >> 2));
>>> }
>>> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
>>> -{
>>> - return irq_get_chip_data(virq);
>>> -}
>>
>> This seems good to me.
>>
>> * We know that this function can't be called directly from outside the
>> file, because it is static.
>>
>> * The function address isn't used as a function pointer anywhere, so
>> that means it can't be called from outside the file that way (also
>> it's inline, which would make using a function pointer unwise!)
>>
>> * There's no obvious macros in that file that might construct the name
>> of the function in a way that is hidden from grep.
>>
>> All in all, I am fairly confident that the function is indeed not used.
>>
>> Reviewed-by: Daniel Axtens <dja@axtens.net>
>>
>> Kind regards,
>> Daniel
>>
>>> -
>>> static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>>> {
>>> return irq_data_get_irq_chip_data(d);
>>> --
>>> 1.8.3.1
Hi,
I will follow the advice and send V2 later.
^ permalink raw reply
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Rick Lindsley @ 2021-04-21 7:54 UTC (permalink / raw)
To: Lijun Pan, Dany Madden
Cc: netdev, Tom Falcon, paulus, Jakub Kicinski, Sukadev Bhattiprolu,
linuxppc-dev, David Miller
In-Reply-To: <60C99F56-617D-455B-9ACF-8CE1EED64D92@linux.vnet.ibm.com>
On 4/20/21 2:42 PM, Lijun Pan wrote:
>
> This v2 does not adddress the concerns mentioned in v1.
> And I think it is better to exit with error from do_reset, and schedule a thorough
> do_hard_reset if the the adapter is already in unstable state.
But the point is that the testing and analysis has indicated that doing a full
hard reset is not necessary. We are about to take the very action which will fix
this situation, but currently do not.
Please describe the advantage in deferring it further by routing it through
do_hard_reset(). I don't see one.
Rick
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/sstep: Add emulation support for ‘setb’ instruction
From: Michael Ellerman @ 2021-04-21 7:30 UTC (permalink / raw)
To: Naveen N. Rao, Daniel Axtens, linuxppc-dev, Sathvika Vasireddy
In-Reply-To: <1618899164.u2uju6vw3c.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com> writes:
> Daniel Axtens wrote:
>> Sathvika Vasireddy <sathvika@linux.vnet.ibm.com> writes:
>>
>>> This adds emulation support for the following instruction:
>>> * Set Boolean (setb)
>>>
>>> Signed-off-by: Sathvika Vasireddy <sathvika@linux.vnet.ibm.com>
...
>>
>> If you do end up respinning the patch, I think it would be good to make
>> the maths a bit clearer. I think it works because a left shift of 2 is
>> the same as multiplying by 4, but it would be easier to follow if you
>> used a temporary variable for btf.
>
> Indeed. I wonder if it is better to follow the ISA itself. Per the ISA,
> the bit we are interested in is:
> 4 x BFA + 32
>
> So, if we use that along with the PPC_BIT() macro, we get:
> if (regs->ccr & PPC_BIT(ra + 32))
Use of PPC_BIT risks annoying your maintainer :)
cheers
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: If kexec_build_elf_info() fails return immediately from elf64_load()
From: Michael Ellerman @ 2021-04-21 7:21 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, robh, dan.carpenter
Cc: devicetree, kbuild-all, lkp, nramas, linuxppc-dev, bauerman, dja
In-Reply-To: <20210420190355.10059-2-nramas@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> Uninitialized local variable "elf_info" would be passed to
> kexec_free_elf_info() if kexec_build_elf_info() returns an error
> in elf64_load().
>
> If kexec_build_elf_info() returns an error, return the error
> immediately.
>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index 02662e72c53d..eeb258002d1e 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -45,7 +45,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
>
> ret = kexec_build_elf_info(kernel_buf, kernel_len, &ehdr, &elf_info);
> if (ret)
> - goto out;
> + return ERR_PTR(ret);
>
> if (image->type == KEXEC_TYPE_CRASH) {
> /* min & max buffer values for kdump case */
> --
> 2.31.0
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Free fdt on error in elf64_load()
From: Michael Ellerman @ 2021-04-21 7:18 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, robh, dan.carpenter
Cc: devicetree, kbuild-all, lkp, nramas, linuxppc-dev, bauerman, dja
In-Reply-To: <20210420190355.10059-1-nramas@linux.microsoft.com>
Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:
> There are a few "goto out;" statements before the local variable "fdt"
> is initialized through the call to of_kexec_alloc_and_setup_fdt() in
> elf64_load(). This will result in an uninitialized "fdt" being passed
> to kvfree() in this function if there is an error before the call to
> of_kexec_alloc_and_setup_fdt().
>
> If there is any error after fdt is allocated, but before it is
> saved in the arch specific kimage struct, free the fdt.
>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
I basically sent you the diff, so this should probably be:
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Otherwise looks good to me, thanks for turning it into a proper patch
and submitting it.
cheers
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index 5a569bb51349..02662e72c53d 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -114,7 +114,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> ret = setup_new_fdt_ppc64(image, fdt, initrd_load_addr,
> initrd_len, cmdline);
> if (ret)
> - goto out;
> + goto out_free_fdt;
>
> fdt_pack(fdt);
>
> @@ -125,7 +125,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> ret = kexec_add_buffer(&kbuf);
> if (ret)
> - goto out;
> + goto out_free_fdt;
>
> /* FDT will be freed in arch_kimage_file_post_load_cleanup */
> image->arch.fdt = fdt;
> @@ -140,18 +140,14 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
> if (ret)
> pr_err("Error setting up the purgatory.\n");
>
> + goto out;
> +
> +out_free_fdt:
> + kvfree(fdt);
> out:
> kfree(modified_cmdline);
> kexec_free_elf_info(&elf_info);
>
> - /*
> - * Once FDT buffer has been successfully passed to kexec_add_buffer(),
> - * the FDT buffer address is saved in image->arch.fdt. In that case,
> - * the memory cannot be freed here in case of any other error.
> - */
> - if (ret && !image->arch.fdt)
> - kvfree(fdt);
> -
> return ret ? ERR_PTR(ret) : NULL;
> }
>
> --
> 2.31.0
^ permalink raw reply
* Re: powerpc{32,64} randconfigs
From: Michael Ellerman @ 2021-04-21 7:15 UTC (permalink / raw)
To: Randy Dunlap, PowerPC; +Cc: linux-kbuild
In-Reply-To: <45afab41-cc5f-dffa-712a-d5fb1a9d0a23@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> Hi,
>
> Is there a way to do this?
>
> $ make ARCH=powerpc randconfig # and force PPC32
Sort of:
$ KCONFIG_ALLCONFIG=arch/powerpc/configs/book3s_32.config make randconfig
But that also forces BOOK3S.
> and separately
> $ make ARCH=powerpc randconfig # and force PPC64
No.
...
> OK, I have a patch that seems for work as far as setting
> PPC32=y or PPC64=y... but it has a problem during linking
> of vmlinux:
>
> crosstool/gcc-9.3.0-nolibc/powerpc-linux/bin/powerpc-linux-ld:./arch/powerpc/kernel/vmlinux.lds:6: syntax error
>
> and the (bad) generated vmlinux.lds file says (at line 6):
>
> OUTPUT_ARCH(1:common)
>
> while it should say:
>
> OUTPUT_ARCH(powerpc:common)
>
> Does anyone have any ideas about this problem?
I guess your patch broke something? :D
Not sure sorry.
What about something like this?
cheers
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3212d076ac6a..712c5e8768ce 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -376,6 +376,16 @@ PHONY += ppc64_book3e_allmodconfig
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
-f $(srctree)/Makefile allmodconfig
+PHONY += ppc32_randconfig
+ppc32_randconfig:
+ $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \
+ -f $(srctree)/Makefile randconfig
+
+PHONY += ppc64_randconfig
+ppc64_randconfig:
+ $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \
+ -f $(srctree)/Makefile randconfig
+
define archhelp
@echo '* zImage - Build default images selected by kernel config'
@echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
diff --git a/arch/powerpc/configs/32-bit.config b/arch/powerpc/configs/32-bit.config
new file mode 100644
index 000000000000..bdf833009006
--- /dev/null
+++ b/arch/powerpc/configs/32-bit.config
@@ -0,0 +1 @@
+CONFIG_PPC64=n
diff --git a/arch/powerpc/configs/64-bit.config b/arch/powerpc/configs/64-bit.config
new file mode 100644
index 000000000000..0fe6406929e2
--- /dev/null
+++ b/arch/powerpc/configs/64-bit.config
@@ -0,0 +1 @@
+CONFIG_PPC64=y
^ permalink raw reply related
* Re: [PATCH v10 05/10] powerpc/bpf: Write protect JIT code
From: Michael Ellerman @ 2021-04-21 6:51 UTC (permalink / raw)
To: Jordan Niethe
Cc: ajd, cmr, Nicholas Piggin, naveen.n.rao, linuxppc-dev,
Daniel Axtens
In-Reply-To: <CACzsE9oERR+KKBe=+eQU1skwTOpDAmi8=_rOMAwM8+LtfBqRKA@mail.gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> On Wed, Mar 31, 2021 at 9:37 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Jordan Niethe <jniethe5@gmail.com> writes:
>>
>> > Once CONFIG_STRICT_MODULE_RWX is enabled there will be no need to
>> > override bpf_jit_free() because it is now possible to set images
>> > read-only. So use the default implementation.
>> >
>> > Also add the necessary call to bpf_jit_binary_lock_ro() which will
>> > remove write protection and add exec protection to the JIT image after
>> > it has finished being written.
>> >
>> > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
>> > ---
>> > v10: New to series
>> > ---
>> > arch/powerpc/net/bpf_jit_comp.c | 5 ++++-
>> > arch/powerpc/net/bpf_jit_comp64.c | 4 ++++
>> > 2 files changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
>> > index e809cb5a1631..8015e4a7d2d4 100644
>> > --- a/arch/powerpc/net/bpf_jit_comp.c
>> > +++ b/arch/powerpc/net/bpf_jit_comp.c
>> > @@ -659,12 +659,15 @@ void bpf_jit_compile(struct bpf_prog *fp)
>> > bpf_jit_dump(flen, proglen, pass, code_base);
>> >
>> > bpf_flush_icache(code_base, code_base + (proglen/4));
>> > -
>> > #ifdef CONFIG_PPC64
>> > /* Function descriptor nastiness: Address + TOC */
>> > ((u64 *)image)[0] = (u64)code_base;
>> > ((u64 *)image)[1] = local_paca->kernel_toc;
>> > #endif
>> > + if (IS_ENABLED(CONFIG_STRICT_MODULE_RWX)) {
>> > + set_memory_ro((unsigned long)image, alloclen >> PAGE_SHIFT);
>> > + set_memory_x((unsigned long)image, alloclen >> PAGE_SHIFT);
>> > + }
>>
>> You don't need to check the ifdef in a caller, there are stubs that
>> compile to nothing when CONFIG_ARCH_HAS_SET_MEMORY=n.
> As Christophe pointed out we could have !CONFIG_STRICT_MODULE_RWX and
> CONFIG_ARCH_HAS_SET_MEMORY which would then be wrong here.
> Probably we could make CONFIG_ARCH_HAS_SET_MEMORY depend on
> CONFIG_STRICT_MODULE_RWX?
I thought it already did depend on it :)
That seems a reasonable dependency to me.
cheers
^ permalink raw reply
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Sukadev Bhattiprolu @ 2021-04-21 6:45 UTC (permalink / raw)
To: Lijun Pan
Cc: netdev, Tom Falcon, paulus, Dany Madden, Jakub Kicinski,
linuxppc-dev, David Miller
In-Reply-To: <60C99F56-617D-455B-9ACF-8CE1EED64D92@linux.vnet.ibm.com>
Lijun Pan [ljp@linux.vnet.ibm.com] wrote:
>
>
> > On Apr 20, 2021, at 4:35 PM, Dany Madden <drt@linux.ibm.com> wrote:
> >
> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > FATAL reset fails and a transmission timeout reset follows, the CRQ is
> > still inactive, ibmvnic's attempt to set link down will also fail. If
> > ibmvnic abandons the reset because of this failed set link down and this
> > is the last reset in the workqueue, then this adapter will be left in an
> > inoperable state.
> >
> > Instead, make the driver ignore this link down failure and continue to
> > free and re-register CRQ so that the adapter has an opportunity to
> > recover.
>
> This v2 does not adddress the concerns mentioned in v1.
> And I think it is better to exit with error from do_reset, and schedule a thorough
> do_hard_reset if the the adapter is already in unstable state.
We had a FATAL error and when handling it, we failed to send a
link-down message to the VIOS. So what we need to try next is to
reset the connection with the VIOS. For this we must talk to the
firmware using the H_FREE_CRQ and H_REG_CRQ hcalls. do_reset()
does just that in ibmvnic_reset_crq().
Now, sure we can attempt a "thorough hard reset" which also does
the same hcalls to reestablish the connection. Is there any
other magic in do_hard_reset()? But in addition, it also frees lot
more Linux kernel buffers and reallocates them for instance.
If we are having a communication problem with the VIOS, what is
the point of freeing and reallocating Linux kernel buffers? Beside
being inefficient, it would expose us to even more errors during
reset under heavy workloads?
From what I understand so far, do_reset() is complicated because
it is attempting some optimizations. If we are going to fall back
to hard reset for every error we might as well drop the do_reset()
and just do the "thorough hard reset" every time right?
The protocol spec is ambiguous and so far I did not get a clear
answer on whether the link-down is even needed. If it is needed,
then should we add it to do_hard_reset() also? If not, we should
remove it (like you mentioned your earlier) completely but am
waiting for confirmation on that. git history has not been helpful.
While there are other rough edges around do_reset() that we are
working on fixing separately (eg: ignore the error return from
__ibmvnic_close() right above this change) I see a benefit to
the customer with this patch.
I am not convinced we should perform a hard reset just because
the link down failed.
Sukadev
^ permalink raw reply
* Re: powerpc{32,64} randconfigs
From: Randy Dunlap @ 2021-04-21 6:45 UTC (permalink / raw)
To: Christophe Leroy, PowerPC; +Cc: linux-kbuild
In-Reply-To: <21339633-16cb-c2ec-1517-2f5c4897fba1@csgroup.eu>
On 4/20/21 11:37 PM, Christophe Leroy wrote:
>
>
> Le 21/04/2021 à 01:31, Randy Dunlap a écrit :
>> --- linux-next-20210420.orig/arch/powerpc/kernel/vdso64/Makefile
>> +++ linux-next-20210420/arch/powerpc/kernel/vdso64/Makefile
>> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-bu
>> asflags-y := -D__VDSO64__ -s
>> targets += vdso64.lds
>> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
>> +CPPFLAGS_vdso64.lds += -P -C -U$(SRCARCH)
>
> Maybe it would be better to do -Upowerpc like in VDSO32
>
OK, thanks for getting that done. :)
>> # link rule for the .so file, .lds has to be first
>> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
>> --- linux-next-20210420.orig/arch/powerpc/Makefile
--
~Randy
^ permalink raw reply
* Re: powerpc{32,64} randconfigs
From: Christophe Leroy @ 2021-04-21 6:37 UTC (permalink / raw)
To: Randy Dunlap, PowerPC; +Cc: linux-kbuild
In-Reply-To: <45afab41-cc5f-dffa-712a-d5fb1a9d0a23@infradead.org>
Le 21/04/2021 à 01:31, Randy Dunlap a écrit :
> --- linux-next-20210420.orig/arch/powerpc/kernel/vdso64/Makefile
> +++ linux-next-20210420/arch/powerpc/kernel/vdso64/Makefile
> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-bu
> asflags-y := -D__VDSO64__ -s
>
> targets += vdso64.lds
> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
> +CPPFLAGS_vdso64.lds += -P -C -U$(SRCARCH)
Maybe it would be better to do -Upowerpc like in VDSO32
>
> # link rule for the .so file, .lds has to be first
> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
> --- linux-next-20210420.orig/arch/powerpc/Makefile
^ 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