* Re: [PATCH v2] powerpc/book3s/kup: Mark the kuap/keup function non __init
From: Michael Ellerman @ 2020-12-15 10:48 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20201214080121.358567-1-aneesh.kumar@linux.ibm.com>
On Mon, 14 Dec 2020 13:31:21 +0530, Aneesh Kumar K.V wrote:
> The kernel call these functions on cpu online and hence they should
> not be marked __init.
Applied to powerpc/next.
[1/1] powerpc/64s: Mark the kuap/kuep functions non __init
https://git.kernel.org/powerpc/c/44b4c4450f8d31296ba633d74be753a85fd627bd
cheers
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
From: Michael Ellerman @ 2020-12-15 10:33 UTC (permalink / raw)
To: Nicholas Piggin, Geert Uytterhoeven
Cc: Peter Zijlstra, Aneesh Kumar K.V, Linux Kernel Mailing List,
Anton Vorontsov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1607943765.29hccd2b8p.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Michael Ellerman's message of December 14, 2020 8:43 pm:
>> Nicholas Piggin <npiggin@gmail.com> writes:
>>> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
>>>> Hi Nicholas,
>>>>
>>>> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>>>>>
>>>>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
>>>>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
>>>>> to manage its TLBs.
>>>>>
>>>>> However the exit_flush_lazy_tlbs() function expects that after
>>>>> returning, all CPUs (except self) have flushed TLBs for that mm, in
>>>>> which case TLBIEL can be used for this flush. This breaks for offline
>>>>> CPUs because they don't get the IPI to flush their TLB. This can lead
>>>>> to stale translations.
>>>>>
>>>>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
>>>>> before going offline.
>>>>>
>>>>> These offlined CPU bits stuck in the cpumask also prevents the cpumask
>>>>> from being trimmed back to local mode, which means continual broadcast
>>>>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
>>>>> situation too.
>>>>>
>>>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>>> --- a/arch/powerpc/platforms/powermac/smp.c
>>>>> +++ b/arch/powerpc/platforms/powermac/smp.c
>>>>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>>>>>
>>>>> mpic_cpu_set_priority(0xf);
>>>>>
>>>>> + cleanup_cpu_mmu_context();
>>>>> +
>>>>
>>>> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
>>>>
>>>> arch/powerpc/platforms/powermac/smp.c: error: implicit
>>>> declaration of function 'cleanup_cpu_mmu_context'
>>>> [-Werror=implicit-function-declaration]: => 914:2
>>>>
>>>> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
>>>
>>> Hey, yeah it does thanks for catching it. This patch fixes it for me
>>>
>>> ---
>>> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001
>>> From: Nicholas Piggin <npiggin@gmail.com>
>>> Date: Mon, 14 Dec 2020 13:52:39 +1000
>>> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
>>>
>>> 32s has no tlbiel_all() defined, so just disable the cleanup with a
>>> comment.
>>
>> Or what about just:
>
> That works, I kind of wanted it in there explicit that we don't
> clean up on 32s. I don't mind if you prefer this though.
OK. I'll merge my version because I can do that without needing to merge
master in order to get the broken commit into my tree.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Inline setup_kup()
From: Michael Ellerman @ 2020-12-15 10:20 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <1ff11fdc-3274-5be3-6968-14084874e212@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 15/12/2020 à 02:42, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
>>>> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
>>>> it must not be __init, because it's used for CPU hotplug, whereas on
>>>> 32-bit it should be __init because it calls setup_kuap/kuep() which
>>>> are __init.
>>>>
>>>> We worked around that problem in the past by marking it __ref, see
>>>> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
>>>> setup_kup()").
>>>>
>>>> Marking it __ref basically just omits it from section mismatch
>>>> checking, which can lead to bugs, and in fact it did, see commit
>>>> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>>>>
>>>> We can avoid all these problems by just making it static inline.
>>>> Because all it does is call other functions, making it inline actually
>>>> shrinks the 32-bit vmlinux by ~76 bytes.
>>>>
>>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>>> ---
>>>> arch/powerpc/include/asm/kup.h | 8 ++++++--
>>>> arch/powerpc/mm/init-common.c | 6 ------
>>>> 2 files changed, 6 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
>>>> index 5a9820c54da9..46b12c6dc728 100644
>>>> --- a/arch/powerpc/include/asm/kup.h
>>>> +++ b/arch/powerpc/include/asm/kup.h
>>>> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>>>>
>>>> #include <linux/pgtable.h>
>>>>
>>>> -void setup_kup(void);
>>>> -
>>>> #ifdef CONFIG_PPC_KUEP
>>>> void setup_kuep(bool disabled);
>>>> #else
>>>> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
>>>> #endif /* CONFIG_PPC_BOOK3S_64 */
>>>> #endif /* CONFIG_PPC_KUAP */
>>>>
>>>> +static inline void setup_kup(void)
>>>
>>> Should it be __always_inline ?
>>
>> Yes I guess so, will fix. Thanks for reviewing.
>>
>
> While we are talking about __always_inline, do you plan to take the following patch this cycle ?
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a1d31f84ddb0926813b17fcd5cc7f3fa7b4deac2.1602759123.git.christophe.leroy@csgroup.eu/
I intended to, will grab it now.
cheers
^ permalink raw reply
* [PATCH V3] powerpc/perf: Fix Threshold Event Counter Multiplier width for P10
From: Athira Rajeev @ 2020-12-15 8:56 UTC (permalink / raw)
To: mpe; +Cc: maddy, linuxppc-dev
From: Madhavan Srinivasan <maddy@linux.ibm.com>
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
In Power10, this is a 8bit field, so patch fixes the
current code to modify the MMCRA[TECM] extraction macro to
handle this change. ISA v3.1 says this is a 7 bit field but
POWER10 it's actually 8 bits which will hopefully be fixed
in ISA v3.1 update.
Fixes: 170a315f41c64 ('powerpc/perf: Support to export MMCRA[TEC*] field to userspace')
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
Changelog v2 -> v3:
- Since in POWER10 it's actually 8 bits which will hopefully be
fixed in ISA3.1 update, bring back the cpu feature check which
is the appropriate one.
Changelog v1 -> v2:
- Fixed the commit message
- Fixed the condition check to use PVR check for power10
instead of ISA v3.1 cpu feature check.
arch/powerpc/perf/isa207-common.c | 3 +++
arch/powerpc/perf/isa207-common.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 24f0a90..6ab5b27 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -247,6 +247,9 @@ void isa207_get_mem_weight(u64 *weight)
u64 sier = mfspr(SPRN_SIER);
u64 val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
+
if (val == 0 || val == 7)
*weight = 0;
else
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 4208764..454b32c 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -231,6 +231,10 @@
#define MMCRA_THR_CTR_EXP(v) (((v) >> MMCRA_THR_CTR_EXP_SHIFT) &\
MMCRA_THR_CTR_EXP_MASK)
+#define P10_MMCRA_THR_CTR_MANT_MASK 0xFFul
+#define P10_MMCRA_THR_CTR_MANT(v) (((v) >> MMCRA_THR_CTR_MANT_SHIFT) &\
+ P10_MMCRA_THR_CTR_MANT_MASK)
+
/* MMCRA Threshold Compare bit constant for power9 */
#define p9_MMCRA_THR_CMP_SHIFT 45
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 1/5] powerpc/smp: Parse ibm,thread-groups with multiple properties
From: Srikar Dronamraju @ 2020-12-15 8:42 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607596739-32439-2-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-10 16:08:55]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> The "ibm,thread-groups" device-tree property is an array that is used
> to indicate if groups of threads within a core share certain
> properties. It provides details of which property is being shared by
> which groups of threads. This array can encode information about
> multiple properties being shared by different thread-groups within the
> core.
>
Looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
From: Srikar Dronamraju @ 2020-12-15 8:44 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607596739-32439-6-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-10 16:08:59]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> On POWER platforms where only some groups of threads within a core
> share the L2-cache (indicated by the ibm,thread-groups device-tree
> property), we currently print the incorrect shared_cpu_map/list for
> L2-cache in the sysfs.
>
> This patch reports the correct shared_cpu_map/list on such platforms.
>
> Example:
> On a platform with "ibm,thread-groups" set to
> 00000001 00000002 00000004 00000000
> 00000002 00000004 00000006 00000001
> 00000003 00000005 00000007 00000002
> 00000002 00000004 00000000 00000002
> 00000004 00000006 00000001 00000003
> 00000005 00000007
>
Looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v3 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
From: Srikar Dronamraju @ 2020-12-15 8:43 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607596739-32439-5-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-10 16:08:58]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> On POWER systems, groups of threads within a core sharing the L2-cache
> can be indicated by the "ibm,thread-groups" property array with the
> identifier "2".
>
> This patch adds support for detecting this, and when present, populate
> the populating the cpu_l2_cache_mask of every CPU to the core-siblings
> which share L2 with the CPU as specified in the by the
> "ibm,thread-groups" property array.
>
> On a platform with the following "ibm,thread-group" configuration
> 00000001 00000002 00000004 00000000
> 00000002 00000004 00000006 00000001
> 00000003 00000005 00000007 00000002
> 00000002 00000004 00000000 00000002
> 00000004 00000006 00000001 00000003
> 00000005 00000007
>
Looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v3 3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic
From: Srikar Dronamraju @ 2020-12-15 8:43 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607596739-32439-4-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-10 16:08:57]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> init_thread_group_l1_cache_map() initializes the per-cpu cpumask
> thread_group_l1_cache_map with the core-siblings which share L1 cache
> with the CPU. Make this function generic to the cache-property (L1 or
> L2) and update a suitable mask. This is a preparatory patch for the
> next patch where we will introduce discovery of thread-groups that
> share L2-cache.
>
> No functional change.
>
Looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
From: Srikar Dronamraju @ 2020-12-15 8:42 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Nathan Lynch, Michael Neuling, Vaidyanathan Srinivasan,
Peter Zijlstra, linux-kernel, Nicholas Piggin, linuxppc-dev,
Valentin Schneider
In-Reply-To: <1607596739-32439-3-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-10 16:08:56]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> On platforms which have the "ibm,thread-groups" property, the per-cpu
> variable cpu_l1_cache_map keeps a track of which group of threads
> within the same core share the L1 cache, Instruction and Data flow.
>
> This patch renames the variable to "thread_group_l1_cache_map" to make
> it consistent with a subsequent patch which will introduce
> thread_group_l2_cache_map.
>
> This patch introduces no functional change.
>
Looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH] powerpc: Inline setup_kup()
From: Christophe Leroy @ 2020-12-15 5:41 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <87czzbzvyg.fsf@mpe.ellerman.id.au>
Le 15/12/2020 à 02:42, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
>>> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
>>> it must not be __init, because it's used for CPU hotplug, whereas on
>>> 32-bit it should be __init because it calls setup_kuap/kuep() which
>>> are __init.
>>>
>>> We worked around that problem in the past by marking it __ref, see
>>> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
>>> setup_kup()").
>>>
>>> Marking it __ref basically just omits it from section mismatch
>>> checking, which can lead to bugs, and in fact it did, see commit
>>> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>>>
>>> We can avoid all these problems by just making it static inline.
>>> Because all it does is call other functions, making it inline actually
>>> shrinks the 32-bit vmlinux by ~76 bytes.
>>>
>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>> ---
>>> arch/powerpc/include/asm/kup.h | 8 ++++++--
>>> arch/powerpc/mm/init-common.c | 6 ------
>>> 2 files changed, 6 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
>>> index 5a9820c54da9..46b12c6dc728 100644
>>> --- a/arch/powerpc/include/asm/kup.h
>>> +++ b/arch/powerpc/include/asm/kup.h
>>> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>>>
>>> #include <linux/pgtable.h>
>>>
>>> -void setup_kup(void);
>>> -
>>> #ifdef CONFIG_PPC_KUEP
>>> void setup_kuep(bool disabled);
>>> #else
>>> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
>>> #endif /* CONFIG_PPC_BOOK3S_64 */
>>> #endif /* CONFIG_PPC_KUAP */
>>>
>>> +static inline void setup_kup(void)
>>
>> Should it be __always_inline ?
>
> Yes I guess so, will fix. Thanks for reviewing.
>
While we are talking about __always_inline, do you plan to take the following patch this cycle ?
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a1d31f84ddb0926813b17fcd5cc7f3fa7b4deac2.1602759123.git.christophe.leroy@csgroup.eu/
Christophe
^ permalink raw reply
* [PATCH] powerpc/boot: Fix build of dts/fsl
From: Michael Ellerman @ 2020-12-15 3:29 UTC (permalink / raw)
To: masahiroy; +Cc: linuxppc-dev
The lkp robot reported that some configs fail to build, for example
mpc85xx_smp_defconfig, with:
cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
This bisects to:
cc8a51ca6f05 ("kbuild: always create directories of targets")
Although that commit claims to be about in-tree builds, it somehow
breaks out-of-tree builds. But presumably it's just exposing a latent
bug in our Makefiles.
We can fix it by adding to targets for dts/fsl in the same way that we
do for dts.
Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/boot/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 68a7534454cd..c3e084cceaed 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -372,6 +372,8 @@ initrd-y := $(filter-out $(image-y), $(initrd-y))
targets += $(image-y) $(initrd-y)
targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
$(patsubst $(x).%, dts/%.dtb, $(filter $(x).%, $(image-y))))
+targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
+ $(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%, $(image-y))))
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: fix comparison to bool warning
From: Paul Mackerras @ 2020-12-15 2:14 UTC (permalink / raw)
To: xiakaixu1987; +Cc: Kaixu Xia, linuxppc-dev, kvm-ppc
In-Reply-To: <1604764178-8087-1-git-send-email-kaixuxia@tencent.com>
On Sat, Nov 07, 2020 at 11:49:38PM +0800, xiakaixu1987@gmail.com wrote:
> From: Kaixu Xia <kaixuxia@tencent.com>
>
> Fix the following coccicheck warning:
>
> ./arch/powerpc/kvm/booke.c:503:6-16: WARNING: Comparison to bool
> ./arch/powerpc/kvm/booke.c:505:6-17: WARNING: Comparison to bool
> ./arch/powerpc/kvm/booke.c:507:6-16: WARNING: Comparison to bool
>
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Assign boolean values to a bool variable
From: Paul Mackerras @ 2020-12-15 2:14 UTC (permalink / raw)
To: xiakaixu1987; +Cc: Kaixu Xia, linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <1604730382-5810-1-git-send-email-kaixuxia@tencent.com>
On Sat, Nov 07, 2020 at 02:26:22PM +0800, xiakaixu1987@gmail.com wrote:
> From: Kaixu Xia <kaixuxia@tencent.com>
>
> Fix the following coccinelle warnings:
>
> ./arch/powerpc/kvm/book3s_xics.c:476:3-15: WARNING: Assignment of 0/1 to bool variable
> ./arch/powerpc/kvm/book3s_xics.c:504:3-15: WARNING: Assignment of 0/1 to bool variable
>
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/kvm: Fix mask size for emulated msgsndp
From: Paul Mackerras @ 2020-12-15 2:15 UTC (permalink / raw)
To: Leonardo Bras; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20201208215707.31149-1-leobras.c@gmail.com>
On Tue, Dec 08, 2020 at 06:57:08PM -0300, Leonardo Bras wrote:
> According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split RB in:
> msgtype <- (RB) 32:36
> payload <- (RB) 37:63
> t <- (RB) 57:63
>
> The current way of getting 'msgtype', and 't' is missing their MSB:
> msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32
> t: (arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
>
> Fixes this by applying the correct mask.
>
> Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* Re: [PATCH] powerpc: Inline setup_kup()
From: Michael Ellerman @ 2020-12-15 1:42 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <09e673ec-6d4e-2e8d-b843-018ce94142a4@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
>> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
>> it must not be __init, because it's used for CPU hotplug, whereas on
>> 32-bit it should be __init because it calls setup_kuap/kuep() which
>> are __init.
>>
>> We worked around that problem in the past by marking it __ref, see
>> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
>> setup_kup()").
>>
>> Marking it __ref basically just omits it from section mismatch
>> checking, which can lead to bugs, and in fact it did, see commit
>> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>>
>> We can avoid all these problems by just making it static inline.
>> Because all it does is call other functions, making it inline actually
>> shrinks the 32-bit vmlinux by ~76 bytes.
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> arch/powerpc/include/asm/kup.h | 8 ++++++--
>> arch/powerpc/mm/init-common.c | 6 ------
>> 2 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
>> index 5a9820c54da9..46b12c6dc728 100644
>> --- a/arch/powerpc/include/asm/kup.h
>> +++ b/arch/powerpc/include/asm/kup.h
>> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>>
>> #include <linux/pgtable.h>
>>
>> -void setup_kup(void);
>> -
>> #ifdef CONFIG_PPC_KUEP
>> void setup_kuep(bool disabled);
>> #else
>> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
>> #endif /* CONFIG_PPC_BOOK3S_64 */
>> #endif /* CONFIG_PPC_KUAP */
>>
>> +static inline void setup_kup(void)
>
> Should it be __always_inline ?
Yes I guess so, will fix. Thanks for reviewing.
cheers
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 44b4c4450f8d31296ba633d74be753a85fd627bd
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 44b4c4450f8d31296ba633d74be753a85fd627bd powerpc/64s: Mark the kuap/kuep functions non __init
elapsed time: 722m
configs tested: 193
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arc axs101_defconfig
sh se7206_defconfig
arm zx_defconfig
powerpc arches_defconfig
arc alldefconfig
powerpc kmeter1_defconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
xtensa xip_kc705_defconfig
mips xway_defconfig
sh rts7751r2dplus_defconfig
powerpc ppa8548_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
sh rsk7269_defconfig
powerpc currituck_defconfig
powerpc mpc83xx_defconfig
mips ip32_defconfig
mips gpr_defconfig
powerpc tqm8540_defconfig
arm bcm2835_defconfig
powerpc socrates_defconfig
mips loongson1b_defconfig
powerpc fsp2_defconfig
mips qi_lb60_defconfig
arm multi_v7_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc pq2fads_defconfig
m68k m5475evb_defconfig
parisc alldefconfig
arm orion5x_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
mips nlm_xlp_defconfig
sh sh03_defconfig
x86_64 alldefconfig
mips bmips_stb_defconfig
mips loongson1c_defconfig
powerpc pmac32_defconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh sdk7786_defconfig
sh titan_defconfig
powerpc gamecube_defconfig
c6x evmc6472_defconfig
sh se7722_defconfig
arm spear6xx_defconfig
mips nlm_xlr_defconfig
mips lemote2f_defconfig
arc nsimosci_defconfig
sh rsk7264_defconfig
arm sunxi_defconfig
sh ap325rxa_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm lart_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 3a6a31edf52760dbc480853232f7bae9867f8e72
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 3a6a31edf52760dbc480853232f7bae9867f8e72 Automatic merge of 'next' into merge (2020-12-14 23:35)
elapsed time: 723m
configs tested: 163
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
sh rts7751r2d1_defconfig
arm hackkit_defconfig
mips bigsur_defconfig
m68k m5275evb_defconfig
i386 defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
arm lart_defconfig
arm milbeaut_m10v_defconfig
sparc sparc32_defconfig
mips ip22_defconfig
xtensa nommu_kc705_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
powerpc kmeter1_defconfig
mips nlm_xlp_defconfig
sh ap325rxa_defconfig
powerpc tqm5200_defconfig
csky alldefconfig
mips pistachio_defconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS bd9161ccbf25eef78b073c239621dfd298222a64
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: bd9161ccbf25eef78b073c239621dfd298222a64 powerpc: Inline setup_kup()
elapsed time: 721m
configs tested: 183
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arc axs101_defconfig
sh se7206_defconfig
arm zx_defconfig
powerpc arches_defconfig
arc alldefconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
xtensa xip_kc705_defconfig
mips xway_defconfig
sh rts7751r2dplus_defconfig
powerpc ppa8548_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
sh rsk7269_defconfig
powerpc currituck_defconfig
powerpc mpc83xx_defconfig
mips ip32_defconfig
mips gpr_defconfig
powerpc tqm8540_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
powerpc kmeter1_defconfig
mips nlm_xlp_defconfig
mips loongson1b_defconfig
sh sh03_defconfig
x86_64 alldefconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh sdk7786_defconfig
sh titan_defconfig
powerpc gamecube_defconfig
c6x evmc6472_defconfig
sh se7722_defconfig
arm spear6xx_defconfig
mips nlm_xlr_defconfig
mips lemote2f_defconfig
arc nsimosci_defconfig
arm at91_dt_defconfig
arm sama5_defconfig
arm mvebu_v5_defconfig
i386 defconfig
mips mpc30x_defconfig
sh ap325rxa_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm lart_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] selftests/powerpc: Add test to check if TM is disabled when it must be
From: Gustavo Romero @ 2020-12-15 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, gustavo.romero
Add a TM test to check that when TM is not advertised by the OS (is disabled) a
transaction can not really be started and generates a SIGILL, which is the right
behavior in that case.
Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
---
tools/testing/selftests/powerpc/tm/.gitignore | 1 +
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-no-tm.c | 48 +++++++++++++++++++++++++++
3 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/tm/tm-no-tm.c
diff --git a/tools/testing/selftests/powerpc/tm/.gitignore b/tools/testing/selftests/powerpc/tm/.gitignore
index d8900a0..1d23309 100644
--- a/tools/testing/selftests/powerpc/tm/.gitignore
+++ b/tools/testing/selftests/powerpc/tm/.gitignore
@@ -20,3 +20,4 @@ tm-unavailable
tm-trap
tm-sigreturn
tm-poison
+tm-no-tm
diff --git a/tools/testing/selftests/powerpc/tm/Makefile b/tools/testing/selftests/powerpc/tm/Makefile
index 5881e97..756a03f 100644
--- a/tools/testing/selftests/powerpc/tm/Makefile
+++ b/tools/testing/selftests/powerpc/tm/Makefile
@@ -5,7 +5,7 @@ SIGNAL_CONTEXT_CHK_TESTS := tm-signal-context-chk-gpr tm-signal-context-chk-fpu
TEST_GEN_PROGS := tm-resched-dscr tm-syscall tm-signal-msr-resv tm-signal-stack \
tm-vmxcopy tm-fork tm-tar tm-tmspr tm-vmx-unavail tm-unavailable tm-trap \
$(SIGNAL_CONTEXT_CHK_TESTS) tm-sigreturn tm-signal-sigreturn-nt \
- tm-signal-context-force-tm tm-poison tm-signal-pagefault
+ tm-signal-context-force-tm tm-poison tm-signal-pagefault tm-no-tm
TEST_FILES := settings
diff --git a/tools/testing/selftests/powerpc/tm/tm-no-tm.c b/tools/testing/selftests/powerpc/tm/tm-no-tm.c
new file mode 100644
index 0000000..3b83e20
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/tm-no-tm.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2020, Gustavo Romero, IBM Corp.
+ *
+ * This test checks if when TM is not supported by the OS indeed it's not
+ * possible to start a TM transaction. Moreover, when trying to start a new
+ * transaction the user gets an illegal instruction, which is the correct
+ * behavior in that case, instead of any other signal, like SIGSEGV etc.
+ *
+ * Since firmware can change the TM instruction behavior in many ways, it's good
+ * to have a test to check if TM is properly disabled when the OS advertises
+ * that TM is not available in userspace.
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <signal.h>
+
+#include "utils.h"
+#include "tm.h"
+
+void illegal_signal_handler(int signo_notused, siginfo_t *si_notused, void *uc_notused)
+{
+ exit(EXIT_SUCCESS);
+}
+
+int tm_no_tm_test(void)
+{
+ struct sigaction illegal_sa;
+
+ SKIP_IF(have_htm());
+
+ illegal_sa.sa_flags = SA_SIGINFO;
+ illegal_sa.sa_sigaction = illegal_signal_handler;
+
+ sigaction(SIGILL, &illegal_sa, NULL);
+
+ /* It must cause a SIGILL since TM is not supported by the OS */
+ asm("tbegin.;");
+
+ return EXIT_FAILURE;
+}
+
+int main(int argc, char **argv)
+{
+ return test_harness(tm_no_tm_test, "tm_no_tm_test");
+}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/3] kbuild: LD_VERSION redenomination
From: Will Deacon @ 2020-12-14 23:05 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Thomas Bogendoerfer, linux-kbuild, Dominique Martinet,
linux-kernel, Jiaxun Yang, linux-mips, Paul Mackerras,
Catalin Marinas, Huacai Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201212165431.150750-2-masahiroy@kernel.org>
On Sun, Dec 13, 2020 at 01:54:30AM +0900, Masahiro Yamada wrote:
> Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
> macros") introduced scripts/ld-version.sh for GCC LTO.
>
> At that time, this script handled 5 version fields because GCC LTO
> needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
>
> The code snippet from the submitted patch was as follows:
>
> # We need HJ Lu's Linux binutils because mainline binutils does not
> # support mixing assembler and LTO code in the same ld -r object.
> # XXX check if the gcc plugin ld is the expected one too
> # XXX some Fedora binutils should also support it. How to check for that?
> ifeq ($(call ld-ifversion,-ge,22710001,y),y)
> ...
>
> However, GCC LTO was not merged into the mainline after all.
> (https://lkml.org/lkml/2014/4/8/272)
>
> So, the 4th and 5th fields were never used, and finally removed by
> commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version
> components").
>
> Since then, the last 4-digits returned by this script is always zeros.
>
> Remove the meaningless last 4-digits. This makes the version format
> consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/arm64/Kconfig | 2 +-
> arch/mips/loongson64/Platform | 2 +-
> arch/mips/vdso/Kconfig | 2 +-
> arch/powerpc/Makefile | 2 +-
> arch/powerpc/lib/Makefile | 2 +-
> scripts/ld-version.sh | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a6b5b7ef40ae..69d56b21a6ec 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1499,7 +1499,7 @@ config ARM64_PTR_AUTH
> depends on (CC_HAS_SIGN_RETURN_ADDRESS || CC_HAS_BRANCH_PROT_PAC_RET) && AS_HAS_PAC
> # Modern compilers insert a .note.gnu.property section note for PAC
> # which is only understood by binutils starting with version 2.33.1.
> - depends on LD_IS_LLD || LD_VERSION >= 233010000 || (CC_IS_GCC && GCC_VERSION < 90100)
> + depends on LD_IS_LLD || LD_VERSION >= 23301 || (CC_IS_GCC && GCC_VERSION < 90100)
> depends on !CC_IS_CLANG || AS_HAS_CFI_NEGATE_RA_STATE
> depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
> help
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Joel Fernandes @ 2020-12-14 18:10 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
zhong jiang, Chinwen Chang, David Rientjes, paulmck, npiggin,
sj38.park, Jerome Glisse, dave, kemi.wang, kirill,
Thomas Gleixner, Haiyan Song, Ganesh Mahendran, Yang Shi,
Mike Rapoport, linuxppc-dev, linux-kernel, Sergey Senozhatsky,
miles.chen, vinayak menon, akpm, Tim Chen, haren
In-Reply-To: <b256e5ed-0d4c-4baf-16a6-f32f122e344f@linux.ibm.com>
On Mon, Dec 14, 2020 at 10:36:29AM +0100, Laurent Dufour wrote:
> Le 14/12/2020 à 03:03, Joel Fernandes a écrit :
> > On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
> > [..]
> > > > > Hi Laurent,
> > > > >
> > > > > We merged SPF v11 and some patches from v12 into our platforms. After
> > > > > several experiments, we observed SPF has obvious improvements on the
> > > > > launch time of applications, especially for those high-TLP ones,
> > > > >
> > > > > # launch time of applications(s):
> > > > >
> > > > > package version w/ SPF w/o SPF improve(%)
> > > > > ------------------------------------------------------------------
> > > > > Baidu maps 10.13.3 0.887 0.98 9.49
> > > > > Taobao 8.4.0.35 1.227 1.293 5.10
> > > > > Meituan 9.12.401 1.107 1.543 28.26
> > > > > WeChat 7.0.3 2.353 2.68 12.20
> > > > > Honor of Kings 1.43.1.6 6.63 6.713 1.24
> > > >
> > > > That's great news, thanks for reporting this!
> > > >
> > > > >
> > > > > By the way, we have verified our platforms with those patches and
> > > > > achieved the goal of mass production.
> > > >
> > > > Another good news!
> > > > For my information, what is your targeted hardware?
> > > >
> > > > Cheers,
> > > > Laurent.
> > >
> > > Hi Laurent,
> > >
> > > Our targeted hardware belongs to ARM64 multi-core series.
> >
> > Hello!
> >
> > I was trying to develop an intuition about why does SPF give improvement for
> > you on small CPU systems. This is just a high-level theory but:
> >
> > 1. Assume the improvement is because of elimination of "blocking" on
> > mmap_sem.
> > Could it be that the mmap_sem is acquired in write-mode unnecessarily in some
> > places, thus causing blocking on mmap_sem in other paths? If so, is it
> > feasible to convert such usages to acquiring them in read-mode?
>
> That's correct, and the goal of this series is to try not holding the
> mmap_sem in read mode during page fault processing.
>
> Converting mmap_sem holder from write to read mode is not so easy and that
> work as already been done in some places. If you think there are areas where
> this could be done, you're welcome to send patches fixing that.
>
> > 2. Assume the improvement is because of lesser read-side contention on
> > mmap_sem.
> > On small CPU systems, I would not expect reducing cache-line bouncing to give
> > such a dramatic improvement in performance as you are seeing.
>
> I don't think cache line bouncing reduction is the main sourcec of
> performance improvement, I would rather think this is the lower part here.
> I guess this is mainly because during loading time a lot of page fault is
> occuring and thus SPF is reducing the contention on the mmap_sem.
Thanks for the reply. I think I also wrongly assumed that acquiring mmap
rwsem in write mode in a syscall makes SPF moot. Peter explained to me on IRC
that tere's still perf improvement in write mode if an unrelated VMA is
modified while another VMA is faulting. CMIIW - not an mm expert by any
stretch.
Thanks!
- Joel
^ permalink raw reply
* Re: [RFC HACK PATCH] PCI: dwc: layerscape: Hack around enumeration problems with Honeycomb LX2K
From: Rob Herring @ 2020-12-14 14:57 UTC (permalink / raw)
To: Daniel Thompson
Cc: Roy Zang, Lorenzo Pieralisi, Linaro Patches, PCI, Jon Nettleton,
linux-kernel@vger.kernel.org, Minghuan Lian, linux-arm-kernel,
Bjorn Helgaas, linuxppc-dev, Mingkai Hu
In-Reply-To: <20201214104337.wbvq2gvj3wi6bvzc@holly.lan>
On Mon, Dec 14, 2020 at 4:43 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Fri, Dec 11, 2020 at 05:05:58PM +0000, Daniel Thompson wrote:
> > On Fri, Dec 11, 2020 at 08:37:40AM -0600, Rob Herring wrote:
> > > On Fri, Dec 11, 2020 at 6:15 AM Daniel Thompson
> > > > BTW I noticed many other pcie-designware drivers take advantage
> > > > of a function called dw_pcie_wait_for_link() in their init paths...
> > > > but my naive attempts to add it to the layerscape driver results
> > > > in non-booting systems so I haven't embarrassed myself by including
> > > > that in the patch!
> > >
> > > You need to look at what's pending for v5.11, because I reworked this
> > > to be more unified. The ordering of init is also possibly changed. The
> > > sequence is now like this:
> > >
> > > dw_pcie_setup_rc(pp);
> > > dw_pcie_msi_init(pp);
> > >
> > > if (!dw_pcie_link_up(pci) && pci->ops->start_link) {
> > > ret = pci->ops->start_link(pci);
> > > if (ret)
> > > goto err_free_msi;
> > > }
> > >
> > > /* Ignore errors, the link may come up later */
> > > dw_pcie_wait_for_link(pci);
> >
> > Thanks. That looks likely to fix it since IIUC dw_pcie_wait_for_link()
> > will end up waiting somewhat like the double check I added to
> > ls_pcie_link_up().
> >
> > I'll take a look at let you know.
>
> Yes. These changes have fixed the enumeration problems for me.
>
> I tested pci/next and I cherry picked your patch series onto v5.10 and
> both are working well.
>
> Given this fixes a bug for me, do you think there is any scope for me
> to whittle down your series into patches for the stable kernels or am
> I likely to find too many extra bits being pulled in?
I think I'd just go the adding a delay route. It's a fairly big series
and depends on my other clean-up done in 5.10. And there's at least
some possibility it regresses some platform given the limited testing
linux-next gets.
Rob
^ permalink raw reply
* [PATCH -next] tty/hvc/hvsi_lib: convert comma to semicolon
From: Zheng Yongjun @ 2020-12-14 13:38 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Zheng Yongjun
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
---
drivers/tty/hvc/hvsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
index 09289c8154ae..8c4ad495f819 100644
--- a/drivers/tty/hvc/hvsi_lib.c
+++ b/drivers/tty/hvc/hvsi_lib.c
@@ -301,7 +301,7 @@ int hvsilib_write_mctrl(struct hvsi_priv *pv, int dtr)
pr_devel("HVSI@%x: %s DTR...\n", pv->termno,
dtr ? "Setting" : "Clearing");
- ctrl.hdr.type = VS_CONTROL_PACKET_HEADER,
+ ctrl.hdr.type = VS_CONTROL_PACKET_HEADER;
ctrl.hdr.len = sizeof(struct hvsi_control);
ctrl.verb = cpu_to_be16(VSV_SET_MODEM_CTL);
ctrl.mask = cpu_to_be32(HVSI_TSDTR);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] powerpc: Inline setup_kup()
From: Christophe Leroy @ 2020-12-14 13:30 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20201214123011.311024-1-mpe@ellerman.id.au>
Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
> it must not be __init, because it's used for CPU hotplug, whereas on
> 32-bit it should be __init because it calls setup_kuap/kuep() which
> are __init.
>
> We worked around that problem in the past by marking it __ref, see
> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
> setup_kup()").
>
> Marking it __ref basically just omits it from section mismatch
> checking, which can lead to bugs, and in fact it did, see commit
> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>
> We can avoid all these problems by just making it static inline.
> Because all it does is call other functions, making it inline actually
> shrinks the 32-bit vmlinux by ~76 bytes.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/kup.h | 8 ++++++--
> arch/powerpc/mm/init-common.c | 6 ------
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
> index 5a9820c54da9..46b12c6dc728 100644
> --- a/arch/powerpc/include/asm/kup.h
> +++ b/arch/powerpc/include/asm/kup.h
> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>
> #include <linux/pgtable.h>
>
> -void setup_kup(void);
> -
> #ifdef CONFIG_PPC_KUEP
> void setup_kuep(bool disabled);
> #else
> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
> #endif /* CONFIG_PPC_BOOK3S_64 */
> #endif /* CONFIG_PPC_KUAP */
>
> +static inline void setup_kup(void)
Should it be __always_inline ?
Christophe
> +{
> + setup_kuep(disable_kuep);
> + setup_kuap(disable_kuap);
> +}
> +
> static inline void allow_read_from_user(const void __user *from, unsigned long size)
> {
> allow_user_access(NULL, from, size, KUAP_READ);
> diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
> index afdebb95bcae..3a82f89827a5 100644
> --- a/arch/powerpc/mm/init-common.c
> +++ b/arch/powerpc/mm/init-common.c
> @@ -47,12 +47,6 @@ static int __init parse_nosmap(char *p)
> }
> early_param("nosmap", parse_nosmap);
>
> -void __ref setup_kup(void)
> -{
> - setup_kuep(disable_kuep);
> - setup_kuap(disable_kuap);
> -}
> -
> #define CTOR(shift) static void ctor_##shift(void *addr) \
> { \
> memset(addr, 0, sizeof(void *) << (shift)); \
>
^ permalink raw reply
* [PATCH] powerpc: Inline setup_kup()
From: Michael Ellerman @ 2020-12-14 12:30 UTC (permalink / raw)
To: linuxppc-dev
setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
it must not be __init, because it's used for CPU hotplug, whereas on
32-bit it should be __init because it calls setup_kuap/kuep() which
are __init.
We worked around that problem in the past by marking it __ref, see
commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
setup_kup()").
Marking it __ref basically just omits it from section mismatch
checking, which can lead to bugs, and in fact it did, see commit
44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
We can avoid all these problems by just making it static inline.
Because all it does is call other functions, making it inline actually
shrinks the 32-bit vmlinux by ~76 bytes.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/kup.h | 8 ++++++--
arch/powerpc/mm/init-common.c | 6 ------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 5a9820c54da9..46b12c6dc728 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -49,8 +49,6 @@ extern bool disable_kuap;
#include <linux/pgtable.h>
-void setup_kup(void);
-
#ifdef CONFIG_PPC_KUEP
void setup_kuep(bool disabled);
#else
@@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
#endif /* CONFIG_PPC_BOOK3S_64 */
#endif /* CONFIG_PPC_KUAP */
+static inline void setup_kup(void)
+{
+ setup_kuep(disable_kuep);
+ setup_kuap(disable_kuap);
+}
+
static inline void allow_read_from_user(const void __user *from, unsigned long size)
{
allow_user_access(NULL, from, size, KUAP_READ);
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index afdebb95bcae..3a82f89827a5 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -47,12 +47,6 @@ static int __init parse_nosmap(char *p)
}
early_param("nosmap", parse_nosmap);
-void __ref setup_kup(void)
-{
- setup_kuep(disable_kuep);
- setup_kuap(disable_kuap);
-}
-
#define CTOR(shift) static void ctor_##shift(void *addr) \
{ \
memset(addr, 0, sizeof(void *) << (shift)); \
--
2.25.1
^ permalink raw reply related
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