* Re: [PATCH v6 09/22] powerpc/exec: Set thread.regs early during exec
From: Christophe Leroy @ 2020-11-25 13:47 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20201125051634.509286-10-aneesh.kumar@linux.ibm.com>
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> In later patches during exec, we would like to access default regs.amr to
> control access to the user mapping. Having thread.regs set early makes the
> code changes simpler.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/thread_info.h | 2 --
> arch/powerpc/kernel/process.c | 37 +++++++++++++++++---------
> 2 files changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
> index 46a210b03d2b..de4c911d9ced 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -77,10 +77,8 @@ struct thread_info {
> /* how to get the thread information struct from C */
> extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
>
> -#ifdef CONFIG_PPC_BOOK3S_64
> void arch_setup_new_exec(void);
> #define arch_setup_new_exec arch_setup_new_exec
> -#endif
>
> #endif /* __ASSEMBLY__ */
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index d421a2c7f822..b6b8a845e454 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1530,10 +1530,32 @@ void flush_thread(void)
> #ifdef CONFIG_PPC_BOOK3S_64
> void arch_setup_new_exec(void)
> {
> - if (radix_enabled())
> - return;
> - hash__setup_new_exec();
> + if (!radix_enabled())
> + hash__setup_new_exec();
> +
> + /*
> + * If we exec out of a kernel thread then thread.regs will not be
> + * set. Do it now.
> + */
> + if (!current->thread.regs) {
> + struct pt_regs *regs = task_stack_page(current) + THREAD_SIZE;
> + current->thread.regs = regs - 1;
> + }
> +
> +}
> +#else
> +void arch_setup_new_exec(void)
> +{
> + /*
> + * If we exec out of a kernel thread then thread.regs will not be
> + * set. Do it now.
> + */
> + if (!current->thread.regs) {
> + struct pt_regs *regs = task_stack_page(current) + THREAD_SIZE;
> + current->thread.regs = regs - 1;
> + }
> }
> +
> #endif
No need to duplicate arch_setup_new_exec() I think. radix_enabled() is defined at all time so the
first function should be valid at all time.
>
> #ifdef CONFIG_PPC64
> @@ -1765,15 +1787,6 @@ void start_thread(struct pt_regs *regs, unsigned long start, unsigned long sp)
> preload_new_slb_context(start, sp);
> #endif
>
> - /*
> - * If we exec out of a kernel thread then thread.regs will not be
> - * set. Do it now.
> - */
> - if (!current->thread.regs) {
> - struct pt_regs *regs = task_stack_page(current) + THREAD_SIZE;
> - current->thread.regs = regs - 1;
> - }
> -
> #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> /*
> * Clear any transactional state, we're exec()ing. The cause is
>
^ permalink raw reply
* Re: [PATCH V3 1/5] ocxl: Assign a register set to a Logical Partition
From: Frederic Barrat @ 2020-11-25 13:47 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, ajd
In-Reply-To: <20201124095838.18665-2-clombard@linux.vnet.ibm.com>
On 24/11/2020 10:58, Christophe Lombard wrote:
> Platform specific function to assign a register set to a Logical Partition.
> The "ibm,mmio-atsd" property, provided by the firmware, contains the 16
> base ATSD physical addresses (ATSD0 through ATSD15) of the set of MMIO
> registers (XTS MMIO ATSDx LPARID/AVA/launch/status register).
>
> For the time being, the ATSD0 set of registers is used by default.
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> ---
Looks good, thanks for the updates!
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
> arch/powerpc/include/asm/pnv-ocxl.h | 3 ++
> arch/powerpc/platforms/powernv/ocxl.c | 45 +++++++++++++++++++++++++++
> 2 files changed, 48 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pnv-ocxl.h b/arch/powerpc/include/asm/pnv-ocxl.h
> index d37ededca3ee..60c3c74427d9 100644
> --- a/arch/powerpc/include/asm/pnv-ocxl.h
> +++ b/arch/powerpc/include/asm/pnv-ocxl.h
> @@ -28,4 +28,7 @@ int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask, void **p
> void pnv_ocxl_spa_release(void *platform_data);
> int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle);
>
> +int pnv_ocxl_map_lpar(struct pci_dev *dev, uint64_t lparid,
> + uint64_t lpcr, void __iomem **arva);
> +void pnv_ocxl_unmap_lpar(void __iomem *arva);
> #endif /* _ASM_PNV_OCXL_H */
> diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c
> index ecdad219d704..57fc1062677b 100644
> --- a/arch/powerpc/platforms/powernv/ocxl.c
> +++ b/arch/powerpc/platforms/powernv/ocxl.c
> @@ -483,3 +483,48 @@ int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
> return rc;
> }
> EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
> +
> +int pnv_ocxl_map_lpar(struct pci_dev *dev, uint64_t lparid,
> + uint64_t lpcr, void __iomem **arva)
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> + u64 mmio_atsd;
> + int rc;
> +
> + /* ATSD physical address.
> + * ATSD LAUNCH register: write access initiates a shoot down to
> + * initiate the TLB Invalidate command.
> + */
> + rc = of_property_read_u64_index(hose->dn, "ibm,mmio-atsd",
> + 0, &mmio_atsd);
> + if (rc) {
> + dev_info(&dev->dev, "No available ATSD found\n");
> + return rc;
> + }
> +
> + /* Assign a register set to a Logical Partition and MMIO ATSD
> + * LPARID register to the required value.
> + */
> + rc = opal_npu_map_lpar(phb->opal_id, pci_dev_id(dev),
> + lparid, lpcr);
> + if (rc) {
> + dev_err(&dev->dev, "Error mapping device to LPAR: %d\n", rc);
> + return rc;
> + }
> +
> + *arva = ioremap(mmio_atsd, 24);
> + if (!(*arva)) {
> + dev_warn(&dev->dev, "ioremap failed - mmio_atsd: %#llx\n", mmio_atsd);
> + rc = -ENOMEM;
> + }
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(pnv_ocxl_map_lpar);
> +
> +void pnv_ocxl_unmap_lpar(void __iomem *arva)
> +{
> + iounmap(arva);
> +}
> +EXPORT_SYMBOL_GPL(pnv_ocxl_unmap_lpar);
>
^ permalink raw reply
* Re: [PATCH v6 07/22] powerpc/book3s64/kuap: Rename MMU_FTR_RADIX_KUAP to MMU_FTR_KUAP
From: Christophe Leroy @ 2020-11-25 13:43 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20201125051634.509286-8-aneesh.kumar@linux.ibm.com>
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> This is in preparate to adding support for kuap with hash translation.
> In preparation for that rename/move kuap related functions to
> non radix names. Also move the feature bit closer to MMU_FTR_KUEP.
It was obvious with MMU_FTR_RADIX_KUAP that it was only for Radix PPC64.
Now, do we expect it to be applies on PPC32 as well or is it still for PPC64 only ?
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/include/asm/book3s/64/kup.h | 18 +++++++++---------
> arch/powerpc/include/asm/mmu.h | 14 +++++++-------
> arch/powerpc/mm/book3s64/pkeys.c | 2 +-
> 3 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/kup.h b/arch/powerpc/include/asm/book3s/64/kup.h
> index 39d2e3a0d64d..1d38eab83d48 100644
> --- a/arch/powerpc/include/asm/book3s/64/kup.h
> +++ b/arch/powerpc/include/asm/book3s/64/kup.h
> @@ -24,7 +24,7 @@
> mtspr SPRN_AMR, \gpr2
> /* No isync required, see kuap_restore_amr() */
> 998:
> - END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_RADIX_KUAP, 67)
> + END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 67)
> #endif
> .endm
>
> @@ -37,7 +37,7 @@
> sldi \gpr2, \gpr2, AMR_KUAP_SHIFT
> 999: tdne \gpr1, \gpr2
> EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE)
> - END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_RADIX_KUAP, 67)
> + END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 67)
> #endif
> .endm
> #endif
> @@ -58,7 +58,7 @@
> mtspr SPRN_AMR, \gpr2
> isync
> 99:
> - END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_RADIX_KUAP, 67)
> + END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 67)
> #endif
> .endm
>
> @@ -73,7 +73,7 @@ DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
>
> static inline void kuap_restore_amr(struct pt_regs *regs, unsigned long amr)
> {
> - if (mmu_has_feature(MMU_FTR_RADIX_KUAP) && unlikely(regs->kuap != amr)) {
> + if (mmu_has_feature(MMU_FTR_KUAP) && unlikely(regs->kuap != amr)) {
> isync();
> mtspr(SPRN_AMR, regs->kuap);
> /*
> @@ -86,7 +86,7 @@ static inline void kuap_restore_amr(struct pt_regs *regs, unsigned long amr)
>
> static inline unsigned long kuap_get_and_check_amr(void)
> {
> - if (mmu_has_feature(MMU_FTR_RADIX_KUAP)) {
> + if (mmu_has_feature(MMU_FTR_KUAP)) {
> unsigned long amr = mfspr(SPRN_AMR);
> if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG)) /* kuap_check_amr() */
> WARN_ON_ONCE(amr != AMR_KUAP_BLOCKED);
> @@ -97,7 +97,7 @@ static inline unsigned long kuap_get_and_check_amr(void)
>
> static inline void kuap_check_amr(void)
> {
> - if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG) && mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG) && mmu_has_feature(MMU_FTR_KUAP))
> WARN_ON_ONCE(mfspr(SPRN_AMR) != AMR_KUAP_BLOCKED);
> }
>
> @@ -116,7 +116,7 @@ static inline unsigned long get_kuap(void)
> * This has no effect in terms of actually blocking things on hash,
> * so it doesn't break anything.
> */
> - if (!early_mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + if (!early_mmu_has_feature(MMU_FTR_KUAP))
> return AMR_KUAP_BLOCKED;
>
> return mfspr(SPRN_AMR);
> @@ -124,7 +124,7 @@ static inline unsigned long get_kuap(void)
>
> static inline void set_kuap(unsigned long value)
> {
> - if (!early_mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + if (!early_mmu_has_feature(MMU_FTR_KUAP))
> return;
>
> /*
> @@ -139,7 +139,7 @@ static inline void set_kuap(unsigned long value)
> static inline bool
> bad_kuap_fault(struct pt_regs *regs, unsigned long address, bool is_write)
> {
> - return WARN(mmu_has_feature(MMU_FTR_RADIX_KUAP) &&
> + return WARN(mmu_has_feature(MMU_FTR_KUAP) &&
> (regs->kuap & (is_write ? AMR_KUAP_BLOCK_WRITE : AMR_KUAP_BLOCK_READ)),
> "Bug: %s fault blocked by AMR!", is_write ? "Write" : "Read");
> }
> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index 255a1837e9f7..f5c7a17c198a 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -28,6 +28,11 @@
> * Individual features below.
> */
>
> +/*
> + * Supports KUAP (key 0 controlling userspace addresses) on radix
> + */
> +#define MMU_FTR_KUAP ASM_CONST(0x00000200)
> +
> /*
> * Support for KUEP feature.
> */
> @@ -120,11 +125,6 @@
> */
> #define MMU_FTR_1T_SEGMENT ASM_CONST(0x40000000)
>
> -/*
> - * Supports KUAP (key 0 controlling userspace addresses) on radix
> - */
> -#define MMU_FTR_RADIX_KUAP ASM_CONST(0x80000000)
> -
> /* MMU feature bit sets for various CPUs */
> #define MMU_FTRS_DEFAULT_HPTE_ARCH_V2 \
> MMU_FTR_HPTE_TABLE | MMU_FTR_PPCAS_ARCH_V2
> @@ -187,10 +187,10 @@ enum {
> #ifdef CONFIG_PPC_RADIX_MMU
> MMU_FTR_TYPE_RADIX |
> MMU_FTR_GTSE |
> +#endif /* CONFIG_PPC_RADIX_MMU */
> #ifdef CONFIG_PPC_KUAP
> - MMU_FTR_RADIX_KUAP |
> + MMU_FTR_KUAP |
> #endif /* CONFIG_PPC_KUAP */
> -#endif /* CONFIG_PPC_RADIX_MMU */
> #ifdef CONFIG_PPC_MEM_KEYS
> MMU_FTR_PKEY |
> #endif
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
> index 82c722fbce52..bfc27f1f0ab0 100644
> --- a/arch/powerpc/mm/book3s64/pkeys.c
> +++ b/arch/powerpc/mm/book3s64/pkeys.c
> @@ -258,7 +258,7 @@ void __init setup_kuap(bool disabled)
>
> if (smp_processor_id() == boot_cpuid) {
> pr_info("Activating Kernel Userspace Access Prevention\n");
> - cur_cpu_spec->mmu_features |= MMU_FTR_RADIX_KUAP;
> + cur_cpu_spec->mmu_features |= MMU_FTR_KUAP;
> }
>
> /*
>
^ permalink raw reply
* Re: [PATCH v6 04/22] powerpc/book3s64/kuap/kuep: Move uamor setup to pkey init
From: Christophe Leroy @ 2020-11-25 13:32 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20201125051634.509286-5-aneesh.kumar@linux.ibm.com>
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> This patch consolidates UAMOR update across pkey, kuap and kuep features.
> The boot cpu initialize UAMOR via pkey init and both radix/hash do the
> secondary cpu UAMOR init in early_init_mmu_secondary.
>
> We don't check for mmu_feature in radix secondary init because UAMOR
> is a supported SPRN with all CPUs supporting radix translation.
> The old code was not updating UAMOR if we had smap disabled and smep enabled.
> This change handles that case.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 3adcf730f478..bfe441af916a 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -620,9 +620,6 @@ void setup_kuap(bool disabled)
> cur_cpu_spec->mmu_features |= MMU_FTR_RADIX_KUAP;
> }
>
> - /* Make sure userspace can't change the AMR */
> - mtspr(SPRN_UAMOR, 0);
> -
> /*
> * Set the default kernel AMR values on all cpus.
> */
> @@ -721,6 +718,11 @@ void radix__early_init_mmu_secondary(void)
>
> radix__switch_mmu_context(NULL, &init_mm);
> tlbiel_all();
> +
> +#ifdef CONFIG_PPC_PKEY
It should be possible to use an 'if' with IS_ENABLED(CONFIG_PPC_PKEY) instead of this #ifdef
> + /* Make sure userspace can't change the AMR */
> + mtspr(SPRN_UAMOR, 0);
> +#endif
> }
>
> void radix__mmu_cleanup_all(void)
>
^ permalink raw reply
* Re: [PATCH v6 03/22] powerpc/book3s64/kuap/kuep: Make KUAP and KUEP a subfeature of PPC_MEM_KEYS
From: Christophe Leroy @ 2020-11-25 13:30 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20201125051634.509286-4-aneesh.kumar@linux.ibm.com>
Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
> The next set of patches adds support for kuap with hash translation.
> Hence make KUAP a BOOK3S_64 feature. Also make it a subfeature of
> PPC_MEM_KEYS. Hash translation is going to use pkeys to support
> KUAP/KUEP. Adding this dependency reduces the code complexity and
> enables us to move some of the initialization code to pkeys.c
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> .../powerpc/include/asm/book3s/64/kup-radix.h | 4 ++--
> arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
> arch/powerpc/include/asm/ptrace.h | 7 +++++-
> arch/powerpc/kernel/asm-offsets.c | 3 +++
> arch/powerpc/mm/book3s64/Makefile | 2 +-
> arch/powerpc/mm/book3s64/pkeys.c | 24 ++++++++++++-------
> arch/powerpc/platforms/Kconfig.cputype | 5 ++++
> 7 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/kup-radix.h b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> index 28716e2f13e3..68eaa2fac3ab 100644
> --- a/arch/powerpc/include/asm/book3s/64/kup-radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> @@ -16,7 +16,7 @@
> #ifdef CONFIG_PPC_KUAP
> BEGIN_MMU_FTR_SECTION_NESTED(67)
> mfspr \gpr1, SPRN_AMR
> - ld \gpr2, STACK_REGS_KUAP(r1)
> + ld \gpr2, STACK_REGS_AMR(r1)
> cmpd \gpr1, \gpr2
> beq 998f
> isync
> @@ -48,7 +48,7 @@
> bne \msr_pr_cr, 99f
> .endif
> mfspr \gpr1, SPRN_AMR
> - std \gpr1, STACK_REGS_KUAP(r1)
> + std \gpr1, STACK_REGS_AMR(r1)
> li \gpr2, (AMR_KUAP_BLOCKED >> AMR_KUAP_SHIFT)
> sldi \gpr2, \gpr2, AMR_KUAP_SHIFT
> cmpd \use_cr, \gpr1, \gpr2
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
> index e0b52940e43c..a2a015066bae 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -199,7 +199,7 @@ extern int mmu_io_psize;
> void mmu_early_init_devtree(void);
> void hash__early_init_devtree(void);
> void radix__early_init_devtree(void);
> -#ifdef CONFIG_PPC_MEM_KEYS
> +#ifdef CONFIG_PPC_PKEY
> void pkey_early_init_devtree(void);
> #else
> static inline void pkey_early_init_devtree(void) {}
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index e2c778c176a3..e7f1caa007a4 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -53,9 +53,14 @@ struct pt_regs
> #ifdef CONFIG_PPC64
> unsigned long ppr;
> #endif
> + union {
> #ifdef CONFIG_PPC_KUAP
> - unsigned long kuap;
> + unsigned long kuap;
> #endif
> +#ifdef CONFIG_PPC_PKEY
> + unsigned long amr;
> +#endif
> + };
> };
> unsigned long __pad[2]; /* Maintain 16 byte interrupt stack alignment */
> };
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index c2722ff36e98..418a0b314a33 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -354,6 +354,9 @@ int main(void)
> STACK_PT_REGS_OFFSET(_PPR, ppr);
> #endif /* CONFIG_PPC64 */
>
> +#ifdef CONFIG_PPC_PKEY
> + STACK_PT_REGS_OFFSET(STACK_REGS_AMR, amr);
> +#endif
> #ifdef CONFIG_PPC_KUAP
> STACK_PT_REGS_OFFSET(STACK_REGS_KUAP, kuap);
> #endif
> diff --git a/arch/powerpc/mm/book3s64/Makefile b/arch/powerpc/mm/book3s64/Makefile
> index fd393b8be14f..1b56d3af47d4 100644
> --- a/arch/powerpc/mm/book3s64/Makefile
> +++ b/arch/powerpc/mm/book3s64/Makefile
> @@ -17,7 +17,7 @@ endif
> obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += hash_hugepage.o
> obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage_prot.o
> obj-$(CONFIG_SPAPR_TCE_IOMMU) += iommu_api.o
> -obj-$(CONFIG_PPC_MEM_KEYS) += pkeys.o
> +obj-$(CONFIG_PPC_PKEY) += pkeys.o
>
> # Instrumenting the SLB fault path can lead to duplicate SLB entries
> KCOV_INSTRUMENT_slb.o := n
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
> index b1d091a97611..7dc71f85683d 100644
> --- a/arch/powerpc/mm/book3s64/pkeys.c
> +++ b/arch/powerpc/mm/book3s64/pkeys.c
> @@ -89,12 +89,14 @@ static int scan_pkey_feature(void)
> }
> }
>
> +#ifdef CONFIG_PPC_MEM_KEYS
> /*
> * Adjust the upper limit, based on the number of bits supported by
> * arch-neutral code.
> */
> pkeys_total = min_t(int, pkeys_total,
> ((ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT) + 1));
I don't think we need an #ifdef here. I thing an 'if (IS_ENABLED(CONFIG_PPC_MEM_KEYS))' should make it.
> +#endif
> return pkeys_total;
> }
>
> @@ -102,6 +104,7 @@ void __init pkey_early_init_devtree(void)
> {
> int pkeys_total, i;
>
> +#ifdef CONFIG_PPC_MEM_KEYS
> /*
> * We define PKEY_DISABLE_EXECUTE in addition to the arch-neutral
> * generic defines for PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE.
> @@ -117,7 +120,7 @@ void __init pkey_early_init_devtree(void)
> BUILD_BUG_ON(__builtin_clzl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT) +
> __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
> != (sizeof(u64) * BITS_PER_BYTE));
> -
> +#endif
> /*
> * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
> */
> @@ -223,14 +226,6 @@ void __init pkey_early_init_devtree(void)
> return;
> }
>
> -void pkey_mm_init(struct mm_struct *mm)
> -{
> - if (!mmu_has_feature(MMU_FTR_PKEY))
> - return;
> - mm_pkey_allocation_map(mm) = initial_allocation_mask;
> - mm->context.execute_only_pkey = execute_only_key;
> -}
> -
> static inline u64 read_amr(void)
> {
> return mfspr(SPRN_AMR);
> @@ -257,6 +252,15 @@ static inline void write_iamr(u64 value)
> mtspr(SPRN_IAMR, value);
> }
>
> +#ifdef CONFIG_PPC_MEM_KEYS
> +void pkey_mm_init(struct mm_struct *mm)
> +{
> + if (!mmu_has_feature(MMU_FTR_PKEY))
> + return;
> + mm_pkey_allocation_map(mm) = initial_allocation_mask;
> + mm->context.execute_only_pkey = execute_only_key;
> +}
> +
> static inline void init_amr(int pkey, u8 init_bits)
> {
> u64 new_amr_bits = (((u64)init_bits & 0x3UL) << pkeyshift(pkey));
> @@ -445,3 +449,5 @@ void arch_dup_pkeys(struct mm_struct *oldmm, struct mm_struct *mm)
> mm_pkey_allocation_map(mm) = mm_pkey_allocation_map(oldmm);
> mm->context.execute_only_pkey = oldmm->context.execute_only_pkey;
> }
> +
> +#endif /* CONFIG_PPC_MEM_KEYS */
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index c194c4ae8bc7..f255e8f32155 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -395,6 +395,11 @@ config PPC_KUAP_DEBUG
> Add extra debugging for Kernel Userspace Access Protection (KUAP)
> If you're unsure, say N.
>
> +config PPC_PKEY
> + def_bool y
> + depends on PPC_BOOK3S_64
> + depends on PPC_MEM_KEYS || PPC_KUAP || PPC_KUEP
> +
> config ARCH_ENABLE_HUGEPAGE_MIGRATION
> def_bool y
> depends on PPC_BOOK3S_64 && HUGETLB_PAGE && MIGRATION
>
^ permalink raw reply
* Re: [PATCH v2 1/2] genirq: add an irq_create_mapping_affinity() function
From: Thomas Gleixner @ 2020-11-25 13:20 UTC (permalink / raw)
To: Laurent Vivier, linux-kernel
Cc: Laurent Vivier, Marc Zyngier, Michael S . Tsirkin, linux-pci,
Greg Kurz, linux-block, Paul Mackerras, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <20201125111657.1141295-2-lvivier@redhat.com>
Laurent,
On Wed, Nov 25 2020 at 12:16, Laurent Vivier wrote:
The proper subsystem prefix is: 'genirq/irqdomain:' and the first letter
after the colon wants to be uppercase.
> This function adds an affinity parameter to irq_create_mapping().
> This parameter is needed to pass it to irq_domain_alloc_descs().
A changelog has to explain the WHY. 'The parameter is needed' is not
really useful information.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/pseries: pass MSI affinity to irq_create_mapping()
From: Greg Kurz @ 2020-11-25 12:51 UTC (permalink / raw)
To: Laurent Vivier
Cc: Michael S . Tsirkin, linux-pci, linux-kernel, linux-block,
Paul Mackerras, Marc Zyngier, Thomas Gleixner, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <20201125111657.1141295-3-lvivier@redhat.com>
On Wed, 25 Nov 2020 12:16:57 +0100
Laurent Vivier <lvivier@redhat.com> wrote:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
> this is broken on pseries.
>
> The affinity is correctly computed in msi_desc but this is not applied
> to the system IRQs.
>
> It appears the affinity is correctly passed to rtas_setup_msi_irqs() but
> lost at this point and never passed to irq_domain_alloc_descs()
> (see commit 06ee6d571f0e ("genirq: Add affinity hint to irq allocation"))
> because irq_create_mapping() doesn't take an affinity parameter.
>
> As the previous patch has added the affinity parameter to
> irq_create_mapping() we can forward the affinity from rtas_setup_msi_irqs()
> to irq_domain_alloc_descs().
>
> With this change, the virtqueues are correctly dispatched between the CPUs
> on pseries.
>
Since it is public, maybe add:
BugId: https://bugzilla.redhat.com/show_bug.cgi?id=1702939
?
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
Anyway,
Reviewed-by: Greg Kurz <groug@kaod.org>
> arch/powerpc/platforms/pseries/msi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
> index 133f6adcb39c..b3ac2455faad 100644
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -458,7 +458,8 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
> return hwirq;
> }
>
> - virq = irq_create_mapping(NULL, hwirq);
> + virq = irq_create_mapping_affinity(NULL, hwirq,
> + entry->affinity);
>
> if (!virq) {
> pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
^ permalink raw reply
* Re: C vdso
From: Michael Ellerman @ 2020-11-25 12:22 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev
In-Reply-To: <20201125102134.Horde.0HRWPh9SlZQBfjT7da-o2A1@messagerie.c-s.fr>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Quoting Michael Ellerman <mpe@ellerman.id.au>:
>
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> Le 03/11/2020 à 19:13, Christophe Leroy a écrit :
>>>> Le 23/10/2020 à 15:24, Michael Ellerman a écrit :
>>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>>> Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
>>>>>>> Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
>>>>>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>>>>>>
>>>>>>>>> What is the status with the generic C vdso merge ?
>>>>>>>>> In some mail, you mentionned having difficulties getting it working on
>>>>>>>>> ppc64, any progress ? What's the problem ? Can I help ?
>>>>>>>>
>>>>>>>> Yeah sorry I was hoping to get time to work on it but haven't been able
>>>>>>>> to.
>>>>>>>>
>>>>>>>> It's causing crashes on ppc64 ie. big endian.
>>>>> ...
>>>>>>>
>>>>>>> Can you tell what defconfig you are using ? I have been able to
>>>>>>> setup a full glibc PPC64 cross
>>>>>>> compilation chain and been able to test it under QEMU with
>>>>>>> success, using Nathan's vdsotest tool.
>>>>>>
>>>>>> What config are you using ?
>>>>>
>>>>> ppc64_defconfig + guest.config
>>>>>
>>>>> Or pseries_defconfig.
>>>>>
>>>>> I'm using Ubuntu GCC 9.3.0 mostly, but it happens with other
>>>>> toolchains too.
>>>>>
>>>>> At a minimum we're seeing relocations in the output, which is a problem:
>>>>>
>>>>> $ readelf -r build\~/arch/powerpc/kernel/vdso64/vdso64.so
>>>>> Relocation section '.rela.dyn' at offset 0x12a8 contains 8 entries:
>>>>> Offset Info Type Sym. Value
>>>>> Sym. Name + Addend
>>>>> 000000001368 000000000016 R_PPC64_RELATIVE 7c0
>>>>> 000000001370 000000000016 R_PPC64_RELATIVE 9300
>>>>> 000000001380 000000000016 R_PPC64_RELATIVE 970
>>>>> 000000001388 000000000016 R_PPC64_RELATIVE 9300
>>>>> 000000001398 000000000016 R_PPC64_RELATIVE a90
>>>>> 0000000013a0 000000000016 R_PPC64_RELATIVE 9300
>>>>> 0000000013b0 000000000016 R_PPC64_RELATIVE b20
>>>>> 0000000013b8 000000000016 R_PPC64_RELATIVE 9300
>>>>
>>>> Looks like it's due to the OPD and relation between the function()
>>>> and .function()
>>>>
>>>> By using DOTSYM() in the 'bl' call, that's directly the dot
>>>> function which is called and the OPD is
>>>> not used anymore, it can get dropped.
>>>>
>>>> Now I get .rela.dyn full of 0, don't know if we should drop it explicitely.
>>>
>>> What is the status now with latest version of CVDSO ? I saw you had
>>> it in next-test for some time,
>>> it is not there anymore today.
>>
>> Still having some trouble with the compat VDSO.
>>
>> eg:
>>
>> $ ./vdsotest clock-gettime-monotonic verify
>> timestamp obtained from kernel predates timestamp
>> previously obtained from libc/vDSO:
>> [1346, 821441653] (vDSO)
>> [570, 769440040] (kernel)
>>
>>
>> And similar for all clocks except the coarse ones.
>>
>
> Ok, I managed to get the same with QEMU. Looking at the binary, I only
> see an mftb instead of the mftbu/mftb/mftbu triplet.
>
> Fix below. Can you carry it, or do you prefer a full patch from me ?
> The easiest would be either to squash it into [v13,4/8]
> ("powerpc/time: Move timebase functions into new asm/timebase.h"), or
> to add it between patch 4 and 5 ?
I can squash it in.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Youling Tang, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1604487550-20040-1-git-send-email-tangyouling@loongson.cn>
On Wed, 4 Nov 2020 18:59:10 +0800, Youling Tang wrote:
> Use the common INIT_DATA_SECTION rule for the linker script in an effort
> to regularize the linker script.
Applied to powerpc/next.
[1/1] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
https://git.kernel.org/powerpc/c/fdcfeaba38e5b183045f5b079af94f97658eabe6
cheers
^ permalink raw reply
* Re: [PATCH] Revert "powerpc/pseries/hotplug-cpu: Remove double free in error path"
From: Michael Ellerman @ 2020-11-25 11:58 UTC (permalink / raw)
To: Zhang Xiaoxu, paulus, groug, tyreld, mpe, benh, linuxppc-dev
In-Reply-To: <20201111020752.1686139-1-zhangxiaoxu5@huawei.com>
On Tue, 10 Nov 2020 21:07:52 -0500, Zhang Xiaoxu wrote:
> This reverts commit a0ff72f9f5a780341e7ff5e9ba50a0dad5fa1980.
>
> Since the commit b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR
> support for drc-info property"), the 'cpu_drcs' wouldn't be double
> freed when the 'cpus' node not found.
>
> So we needn't apply this patch, otherwise, the memory will be leak.
Applied to powerpc/next.
[1/1] Revert "powerpc/pseries/hotplug-cpu: Remove double free in error path"
https://git.kernel.org/powerpc/c/a40fdaf1420d6e6bda0dd2df1e6806013e58dbe1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
From: Michael Ellerman @ 2020-11-25 11:58 UTC (permalink / raw)
To: ajd, paulus, fbarrat, mpe, xiakaixu1987@gmail.com, benh
Cc: linuxppc-dev, Kaixu Xia, linux-kernel
In-Reply-To: <1605007170-22171-1-git-send-email-kaixuxia@tencent.com>
On Tue, 10 Nov 2020 19:19:30 +0800, xiakaixu1987@gmail.com wrote:
> Fix coccicheck warning:
>
> ./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned expression compared with zero: win < 0
> ./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned expression compared with zero: win < 0
Applied to powerpc/next.
[1/1] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
https://git.kernel.org/powerpc/c/027717a45ca251a7ba67a63db359994836962cd2
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix comparing pointer to 0 warning
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: paulus, xiakaixu1987@gmail.com, mpe, benh
Cc: linuxppc-dev, Kaixu Xia, linux-kernel
In-Reply-To: <1604976961-20441-1-git-send-email-kaixuxia@tencent.com>
On Tue, 10 Nov 2020 10:56:01 +0800, xiakaixu1987@gmail.com wrote:
> Fixes coccicheck warning:
>
> ./arch/powerpc/mm/pgtable_32.c:87:11-12: WARNING comparing pointer to 0
>
> Avoid pointer type value compared to 0.
Applied to powerpc/next.
[1/1] powerpc/mm: Fix comparing pointer to 0 warning
https://git.kernel.org/powerpc/c/b84bf098fcc49ed6bf4b0a8bed52e9df0e8f1de7
cheers
^ permalink raw reply
* Re: [PATCHv2] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Po-Hsu Lin, mpe, linux-kselftest, linux-kernel, linuxppc-dev
Cc: mathieu.desnoyers, shuah, joe.lawrence, mbenes
In-Reply-To: <20201023024539.9512-1-po-hsu.lin@canonical.com>
On Fri, 23 Oct 2020 10:45:39 +0800, Po-Hsu Lin wrote:
> The eeh-basic test got its own 60 seconds timeout (defined in commit
> 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
> device.
>
> And we have discovered that the number of breakable devices varies
> on different hardware. The device recovery time ranges from 0 to 35
> seconds. In our test pool it will take about 30 seconds to run on a
> Power8 system that with 5 breakable devices, 60 seconds to run on a
> Power9 system that with 4 breakable devices.
>
> [...]
Applied to powerpc/next.
[1/1] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic
https://git.kernel.org/powerpc/c/f5eca0b279117f25020112a2f65ec9c3ea25f3ac
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/ps3: Drop unused DBG macro
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20201023031305.3284819-1-mpe@ellerman.id.au>
On Fri, 23 Oct 2020 14:13:05 +1100, Michael Ellerman wrote:
> This DBG macro is unused, and has been unused since the file was
> originally merged into mainline. Just drop it.
Applied to powerpc/next.
[1/1] powerpc/ps3: Drop unused DBG macro
https://git.kernel.org/powerpc/c/cb5d4c465f31bc44b8bbd4934678c2b140a2ad29
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Fix declaration made after definition
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20201023020838.3274226-1-mpe@ellerman.id.au>
On Fri, 23 Oct 2020 13:08:38 +1100, Michael Ellerman wrote:
> Currently the clang build of corenet64_smp_defconfig fails with:
>
> arch/powerpc/platforms/85xx/corenet_generic.c:210:1: error:
> attribute declaration must precede definition
> machine_arch_initcall(corenet_generic, corenet_gen_publish_devices);
>
> Fix it by moving the initcall definition prior to the machine
> definition, and directly below the function it calls, which is the
> usual style anyway.
Applied to powerpc/next.
[1/1] powerpc/85xx: Fix declaration made after definition
https://git.kernel.org/powerpc/c/ef78f2dd2398ce8ed9eeaab9c9f8af2e15f5d870
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: sysdev: add missing iounmap() on error in mpic_msgr_probe()
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Qinglang Miao, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20201028091551.136400-1-miaoqinglang@huawei.com>
On Wed, 28 Oct 2020 17:15:51 +0800, Qinglang Miao wrote:
> I noticed that iounmap() of msgr_block_addr before return from
> mpic_msgr_probe() in the error handling case is missing. So use
> devm_ioremap() instead of just ioremap() when remapping the message
> register block, so the mapping will be automatically released on
> probe failure.
Applied to powerpc/next.
[1/1] powerpc: sysdev: add missing iounmap() on error in mpic_msgr_probe()
https://git.kernel.org/powerpc/c/ffa1797040c5da391859a9556be7b735acbe1242
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s/perf: perf interrupt does not have to get_user_pages to access user memory
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20201111120151.3150658-1-npiggin@gmail.com>
On Wed, 11 Nov 2020 22:01:51 +1000, Nicholas Piggin wrote:
> read_user_stack_slow that walks user address translation by hand is
> only required on hash, because a hash fault can not be serviced from
> "NMI" context (to avoid re-entering the hash code) so the user stack
> can be mapped into Linux page tables but not accessible by the CPU.
>
> Radix MMU mode does not have this restriction. A page fault failure
> would indicate the page is not accessible via get_user_pages either,
> so avoid this on radix.
Applied to powerpc/next.
[1/1] powerpc/64s/perf: perf interrupt does not have to get_user_pages to access user memory
https://git.kernel.org/powerpc/c/987c426320cce72d1b28f55c8603b239e4f7187c
cheers
^ permalink raw reply
* Re: [PATCH v2 0/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: linux-kernel, David Hildenbrand
Cc: Michal Hocko, Wei Yang, Nicholas Piggin, Michal Hocko, linux-mm,
Paul Mackerras, Aneesh Kumar K.V, Rashmica Gupta, linuxppc-dev,
Andrew Morton, Mike Rapoport, Oscar Salvador
In-Reply-To: <20201111145322.15793-1-david@redhat.com>
On Wed, 11 Nov 2020 15:53:14 +0100, David Hildenbrand wrote:
> Based on latest linux/master
>
> powernv/memtrace is the only in-kernel user that rips out random memory
> it never added (doesn't own) in order to allocate memory without a
> linear mapping. Let's stop abusing memory hot(un)plug infrastructure for
> that - use alloc_contig_pages() for allocating memory and remove the
> linear mapping manually.
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/powernv/memtrace: Don't leak kernel memory to user space
https://git.kernel.org/powerpc/c/c74cf7a3d59a21b290fe0468f5b470d0b8ee37df
[2/8] powerpc/powernv/memtrace: Fix crashing the kernel when enabling concurrently
https://git.kernel.org/powerpc/c/d6718941a2767fb383e105d257d2105fe4f15f0e
[3/8] powerpc/mm: factor out creating/removing linear mapping
https://git.kernel.org/powerpc/c/4abb1e5b63ac3281275315fc6b0cde0b9c2e2e42
[4/8] powerpc/mm: protect linear mapping modifications by a mutex
https://git.kernel.org/powerpc/c/e5b2af044f31bf18defa557a8cd11c23caefa34c
[5/8] powerpc/mm: print warning in arch_remove_linear_mapping()
https://git.kernel.org/powerpc/c/1f73ad3e8d755dbec52fcec98618a7ce4de12af2
[6/8] powerpc/book3s64/hash: Drop WARN_ON in hash__remove_section_mapping()
https://git.kernel.org/powerpc/c/d8bd9a121c2f2bc8b36da930dc91b69fd2a705e2
[7/8] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
https://git.kernel.org/powerpc/c/ca2c36cae9d48b180ea51259e35ab3d95d327df2
[8/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
https://git.kernel.org/powerpc/c/0bd4b96d99108b7ea9bac0573957483be7781d70
cheers
^ permalink raw reply
* Re: [PATCH v4 1/2] powerpc/64: Set up a kernel stack for secondaries before cpu_restore()
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev; +Cc: oohall, npiggin
In-Reply-To: <20201014072837.24539-1-jniethe5@gmail.com>
On Wed, 14 Oct 2020 18:28:36 +1100, Jordan Niethe wrote:
> Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore()
> is called before a stack has been set up in r1. This was previously fine
> as the cpu_restore() functions were implemented in assembly and did not
> use a stack. However commit 5a61ef74f269 ("powerpc/64s: Support new
> device tree binding for discovering CPU features") used
> __restore_cpu_cpufeatures() as the cpu_restore() function for a
> device-tree features based cputable entry. This is a C function and
> hence uses a stack in r1.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/64: Set up a kernel stack for secondaries before cpu_restore()
https://git.kernel.org/powerpc/c/3c0b976bf20d236c57adcefa80f86a0a1d737727
[2/2] powerpc/64s: Convert some cpu_setup() and cpu_restore() functions to C
https://git.kernel.org/powerpc/c/344fbab991a568dc33ad90711b489d870e18d26d
cheers
^ permalink raw reply
* Re: [PATCH v1 0/4] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: linux-kernel, David Hildenbrand
Cc: Michal Hocko, Wei Yang, Michal Hocko, linux-mm, Paul Mackerras,
Rashmica Gupta, linuxppc-dev, Andrew Morton, Mike Rapoport,
Oscar Salvador
In-Reply-To: <20201029162718.29910-1-david@redhat.com>
On Thu, 29 Oct 2020 17:27:14 +0100, David Hildenbrand wrote:
> powernv/memtrace is the only in-kernel user that rips out random memory
> it never added (doesn't own) in order to allocate memory without a
> linear mapping. Let's stop abusing memory hot(un)plug infrastructure for
> that - use alloc_contig_pages() for allocating memory and remove the
> linear mapping manually.
>
> The original idea was discussed in:
> https://lkml.kernel.org/r/48340e96-7e6b-736f-9e23-d3111b915b6e@redhat.com
>
> [...]
Applied to powerpc/next.
[1/4] powerpc/mm: factor out creating/removing linear mapping
https://git.kernel.org/powerpc/c/4abb1e5b63ac3281275315fc6b0cde0b9c2e2e42
[2/4] powerpc/mm: print warning in arch_remove_linear_mapping()
https://git.kernel.org/powerpc/c/1f73ad3e8d755dbec52fcec98618a7ce4de12af2
[3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
https://git.kernel.org/powerpc/c/ca2c36cae9d48b180ea51259e35ab3d95d327df2
[4/4] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
https://git.kernel.org/powerpc/c/0bd4b96d99108b7ea9bac0573957483be7781d70
cheers
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7719261b0a0d2787772339484c33eb809723bca7.1604854583.git.christophe.leroy@csgroup.eu>
On Sun, 8 Nov 2020 16:57:35 +0000 (UTC), Christophe Leroy wrote:
> In head_64.S, we have two places using RFI to return to
> kernel. Use RFI_TO_KERNEL instead.
>
> They are the two only places using RFI on book3s/64, so
> the RFI macro can go away.
Applied to powerpc/next.
[1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI
https://git.kernel.org/powerpc/c/879add7720172ffd2986c44587510fabb7af52f5
[2/3] powerpc: Replace RFI by rfi on book3s/32 and booke
https://git.kernel.org/powerpc/c/120c0518ec321f33cdc4670059fb76e96ceb56eb
[3/3] powerpc: Remove RFI macro
https://git.kernel.org/powerpc/c/62182e6c0faf75117f8d1719c118bb5fc8574012
cheers
^ permalink raw reply
* Re: [PATCH v13 0/8] powerpc: switch VDSO to C implementation
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, anton, Benjamin Herrenschmidt,
Christophe Leroy, nathanl
Cc: linux-arch, arnd, linux-kernel, luto, tglx, vincenzo.frascino,
linuxppc-dev
In-Reply-To: <cover.1604426550.git.christophe.leroy@csgroup.eu>
On Tue, 3 Nov 2020 18:07:11 +0000 (UTC), Christophe Leroy wrote:
> This is a series to switch powerpc VDSO to generic C implementation.
>
> Changes in v13:
> - Reorganised headers to avoid the need for a fake 32 bits config for building VDSO32 on PPC64
> - Rebased after the removal of powerpc 601
> - Using DOTSYM() macro to call functions directly without using OPD
> - Explicitely dropped .opd and .got1 sections which are now unused
>
> [...]
Patch 1 applied to powerpc/next.
[1/8] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
https://git.kernel.org/powerpc/c/78665179e569c7e1fe102fb6c21d0f5b6951f084
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/bitops: Fix possible undefined behaviour with fls() and fls64()
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, jakub, Benjamin Herrenschmidt,
Christophe Leroy, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <348c2d3f19ffcff8abe50d52513f989c4581d000.1603375524.git.christophe.leroy@csgroup.eu>
On Thu, 22 Oct 2020 14:05:46 +0000 (UTC), Christophe Leroy wrote:
> fls() and fls64() are using __builtin_ctz() and _builtin_ctzll().
> On powerpc, those builtins trivially use ctlzw and ctlzd power
> instructions.
>
> Allthough those instructions provide the expected result with
> input argument 0, __builtin_ctz() and __builtin_ctzll() are
> documented as undefined for value 0.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/bitops: Fix possible undefined behaviour with fls() and fls64()
https://git.kernel.org/powerpc/c/1891ef21d92c4801ea082ee8ed478e304ddc6749
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: avoid broken GCC __attribute__((optimize))
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: linux-kernel, Ard Biesheuvel
Cc: Kees Cook, Daniel Borkmann, Peter Zijlstra, Randy Dunlap,
Nick Desaulniers, Alexei Starovoitov, Arvind Sankar,
Paul Mackerras, Josh Poimboeuf, Geert Uytterhoeven,
Thomas Gleixner, linuxppc-dev
In-Reply-To: <20201028080433.26799-1-ardb@kernel.org>
On Wed, 28 Oct 2020 09:04:33 +0100, Ard Biesheuvel wrote:
> Commit 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
> introduced a couple of uses of __attribute__((optimize)) with function
> scope, to disable the stack protector in some early boot code.
>
> Unfortunately, and this is documented in the GCC man pages [0], overriding
> function attributes for optimization is broken, and is only supported for
> debug scenarios, not for production: the problem appears to be that
> setting GCC -f flags using this method will cause it to forget about some
> or all other optimization settings that have been applied.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Avoid broken GCC __attribute__((optimize))
https://git.kernel.org/powerpc/c/a7223f5bfcaeade4a86d35263493bcda6c940891
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Update tlbiel loop on POWER10
From: Michael Ellerman @ 2020-11-25 11:57 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe; +Cc: npiggin
In-Reply-To: <20201007053305.232879-1-aneesh.kumar@linux.ibm.com>
On Wed, 7 Oct 2020 11:03:05 +0530, Aneesh Kumar K.V wrote:
> With POWER10, single tlbiel instruction invalidates all the congruence
> class of the TLB and hence we need to issue only one tlbiel with SET=0.
Applied to powerpc/next.
[1/1] powerpc/mm: Update tlbiel loop on POWER10
https://git.kernel.org/powerpc/c/e80639405c40127727812a0e1f8a65ba9979f146
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