* Re: [PATCH v4 6/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Ricardo Neri @ 2021-08-27 19:45 UTC (permalink / raw)
To: Vincent Guittot
Cc: Juri Lelli, Aubrey Li, Srikar Dronamraju, Ravi V. Shankar,
Peter Zijlstra (Intel), Ricardo Neri, Ben Segall,
Srinivas Pandruvada, Joel Fernandes (Google), Ingo Molnar,
Rafael J. Wysocki, Steven Rostedt, Mel Gorman, Len Brown,
Nicholas Piggin, Aubrey Li, Dietmar Eggemann, Tim Chen,
Quentin Perret, Daniel Bristot de Oliveira, linux-kernel,
linuxppc-dev
In-Reply-To: <CAKfTPtArtmhLG5QYR6TzKevDrEuiQu2HJxm_C3pe549XdGU-1g@mail.gmail.com>
On Fri, Aug 27, 2021 at 12:13:42PM +0200, Vincent Guittot wrote:
> On Tue, 10 Aug 2021 at 16:41, Ricardo Neri
> <ricardo.neri-calderon@linux.intel.com> wrote:
> > @@ -9540,6 +9629,12 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> > nr_running == 1)
> > continue;
> >
> > + /* Make sure we only pull tasks from a CPU of lower priority */
> > + if ((env->sd->flags & SD_ASYM_PACKING) &&
> > + sched_asym_prefer(i, env->dst_cpu) &&
> > + nr_running == 1)
> > + continue;
>
> This really looks similar to the test above for SD_ASYM_CPUCAPACITY.
> More generally speaking SD_ASYM_PACKING and SD_ASYM_CPUCAPACITY share
> a lot of common policy and I wonder if at some point we could not
> merge their behavior in LB
I would like to confirm with you that you are not expecting this merge
as part of this series, right?
Thanks and BR,
Ricardo
^ permalink raw reply
* [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Christophe JAILLET @ 2021-08-27 19:56 UTC (permalink / raw)
To: kou.ishizaki, geoff, davem, kuba
Cc: netdev, kernel-janitors, Christophe JAILLET, linuxppc-dev,
linux-kernel
In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.
Some reasons why this API should be removed have been given by Julia
Lawall in [2].
A coccinelle script has been used to perform the needed transformation
Only relevant parts are given below.
@@ @@
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
@@ @@
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
@@ @@
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
@@
expression e1, e2, e3, e4;
@@
- pci_map_single(e1, e2, e3, e4)
+ dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
- pci_unmap_single(e1, e2, e3, e4)
+ dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
- pci_dma_mapping_error(e1, e2)
+ dma_mapping_error(&e1->dev, e2)
[1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
[2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
It has *not* been compile tested because I don't have the needed
configuration or cross-compiler. However, the modification is completely
mechanical and done by coccinelle.
---
drivers/net/ethernet/toshiba/spider_net.c | 27 +++++++++++++----------
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 087f0af56c50..66d4e024d11e 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -354,9 +354,10 @@ spider_net_free_rx_chain_contents(struct spider_net_card *card)
descr = card->rx_chain.head;
do {
if (descr->skb) {
- pci_unmap_single(card->pdev, descr->hwdescr->buf_addr,
+ dma_unmap_single(&card->pdev->dev,
+ descr->hwdescr->buf_addr,
SPIDER_NET_MAX_FRAME,
- PCI_DMA_BIDIRECTIONAL);
+ DMA_BIDIRECTIONAL);
dev_kfree_skb(descr->skb);
descr->skb = NULL;
}
@@ -411,9 +412,9 @@ spider_net_prepare_rx_descr(struct spider_net_card *card,
if (offset)
skb_reserve(descr->skb, SPIDER_NET_RXBUF_ALIGN - offset);
/* iommu-map the skb */
- buf = pci_map_single(card->pdev, descr->skb->data,
- SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
- if (pci_dma_mapping_error(card->pdev, buf)) {
+ buf = dma_map_single(&card->pdev->dev, descr->skb->data,
+ SPIDER_NET_MAX_FRAME, DMA_FROM_DEVICE);
+ if (dma_mapping_error(&card->pdev->dev, buf)) {
dev_kfree_skb_any(descr->skb);
descr->skb = NULL;
if (netif_msg_rx_err(card) && net_ratelimit())
@@ -653,8 +654,9 @@ spider_net_prepare_tx_descr(struct spider_net_card *card,
dma_addr_t buf;
unsigned long flags;
- buf = pci_map_single(card->pdev, skb->data, skb->len, PCI_DMA_TODEVICE);
- if (pci_dma_mapping_error(card->pdev, buf)) {
+ buf = dma_map_single(&card->pdev->dev, skb->data, skb->len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(&card->pdev->dev, buf)) {
if (netif_msg_tx_err(card) && net_ratelimit())
dev_err(&card->netdev->dev, "could not iommu-map packet (%p, %i). "
"Dropping packet\n", skb->data, skb->len);
@@ -666,7 +668,8 @@ spider_net_prepare_tx_descr(struct spider_net_card *card,
descr = card->tx_chain.head;
if (descr->next == chain->tail->prev) {
spin_unlock_irqrestore(&chain->lock, flags);
- pci_unmap_single(card->pdev, buf, skb->len, PCI_DMA_TODEVICE);
+ dma_unmap_single(&card->pdev->dev, buf, skb->len,
+ DMA_TO_DEVICE);
return -ENOMEM;
}
hwdescr = descr->hwdescr;
@@ -822,8 +825,8 @@ spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
/* unmap the skb */
if (skb) {
- pci_unmap_single(card->pdev, buf_addr, skb->len,
- PCI_DMA_TODEVICE);
+ dma_unmap_single(&card->pdev->dev, buf_addr, skb->len,
+ DMA_TO_DEVICE);
dev_consume_skb_any(skb);
}
}
@@ -1165,8 +1168,8 @@ spider_net_decode_one_descr(struct spider_net_card *card)
/* unmap descriptor */
hw_buf_addr = hwdescr->buf_addr;
hwdescr->buf_addr = 0xffffffff;
- pci_unmap_single(card->pdev, hw_buf_addr,
- SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
+ dma_unmap_single(&card->pdev->dev, hw_buf_addr, SPIDER_NET_MAX_FRAME,
+ DMA_FROM_DEVICE);
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v2 4/5] KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs
From: Sean Christopherson @ 2021-08-27 23:23 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: KVM list, Peter Zijlstra, Catalin Marinas, linux-kernel,
Will Deacon, Guo Ren, linux-kselftest, Ben Gardon, shuah,
Paul Mackerras, linux-s390, gor, Russell King, ARM Linux,
linux-csky, Christian Borntraeger, Ingo Molnar, dvhart,
linux-mips, Boqun Feng, paulmck, Heiko Carstens, rostedt,
Shakeel Butt, Andy Lutomirski, Thomas Gleixner, Peter Foley,
linux-arm-kernel, Thomas Bogendoerfer, Oleg Nesterov,
Paolo Bonzini, linuxppc-dev
In-Reply-To: <339641531.29941.1630091374065.JavaMail.zimbra@efficios.com>
On Fri, Aug 27, 2021, Mathieu Desnoyers wrote:
> > So there are effectively three reasons we want a delay:
> >
> > 1. To allow sched_setaffinity() to coincide with ioctl(KVM_RUN) before KVM can
> > enter the guest so that the guest doesn't need an arch-specific VM-Exit source.
> >
> > 2. To let ioctl(KVM_RUN) make its way back to the test before the next round
> > of migration.
> >
> > 3. To ensure the read-side can make forward progress, e.g. if sched_getcpu()
> > involves a syscall.
> >
> >
> > After looking at KVM for arm64 and s390, #1 is a bit tenuous because x86 is the
> > only arch that currently uses xfer_to_guest_mode_work(), i.e. the test could be
> > tweaked to be overtly x86-specific. But since a delay is needed for #2 and #3,
> > I'd prefer to rely on it for #1 as well in the hopes that this test provides
> > coverage for arm64 and/or s390 if they're ever converted to use the common
> > xfer_to_guest_mode_work().
>
> Now that we have this understanding of why we need the delay, it would be good to
> write this down in a comment within the test.
Ya, I'll get a new version out next week.
> Does it reproduce if we randomize the delay to have it picked randomly from 0us
> to 100us (with 1us step) ? It would remove a lot of the needs for arch-specific
> magic delay value.
My less-than-scientific testing shows that it can reproduce at delays up to ~500us,
but above ~10us the reproducibility starts to drop. The bug still reproduces
reliably, it just takes more iterations, and obviously the test runs a bit slower.
Any objection to using a 1-10us delay, e.g. a simple usleep((i % 10) + 1)?
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs
From: Mathieu Desnoyers @ 2021-08-28 0:06 UTC (permalink / raw)
To: Sean Christopherson
Cc: KVM list, Peter Zijlstra, Catalin Marinas, linux-kernel,
Will Deacon, Guo Ren, linux-kselftest, Ben Gardon, shuah,
Paul Mackerras, linux-s390, gor, Russell King, ARM Linux,
linux-csky, Christian Borntraeger, Ingo Molnar, dvhart,
linux-mips, Boqun Feng, paulmck, Heiko Carstens, rostedt,
Shakeel Butt, Andy Lutomirski, Thomas Gleixner, Peter Foley,
linux-arm-kernel, Thomas Bogendoerfer, Oleg Nesterov,
Paolo Bonzini, linuxppc-dev
In-Reply-To: <YSlz8h9SWgeuicak@google.com>
----- On Aug 27, 2021, at 7:23 PM, Sean Christopherson seanjc@google.com wrote:
> On Fri, Aug 27, 2021, Mathieu Desnoyers wrote:
[...]
>> Does it reproduce if we randomize the delay to have it picked randomly from 0us
>> to 100us (with 1us step) ? It would remove a lot of the needs for arch-specific
>> magic delay value.
>
> My less-than-scientific testing shows that it can reproduce at delays up to
> ~500us,
> but above ~10us the reproducibility starts to drop. The bug still reproduces
> reliably, it just takes more iterations, and obviously the test runs a bit
> slower.
>
> Any objection to using a 1-10us delay, e.g. a simple usleep((i % 10) + 1)?
Works for me, thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Geoff Levand @ 2021-08-28 1:34 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <60abc3d0c8b4ef8368a4d63326a25a5cb3cd218c.1630094078.git.christophe.jaillet@wanadoo.fr>
Hi Christophe,
On 8/27/21 12:56 PM, Christophe JAILLET wrote:
> It has *not* been compile tested because I don't have the needed
> configuration or cross-compiler.
The powerpc ppc64_defconfig has CONFIG_SPIDER_NET set. My
tdd-builder Docker image has the needed gcc-powerpc-linux-gnu
cross compiler to build ppc64_defconfig:
https://hub.docker.com/r/glevand/tdd-builder
-Geoff
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Christophe Leroy @ 2021-08-28 9:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210827163410.1177154-5-npiggin@gmail.com>
Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
> MMU code to be compiled out if radix is selected and the minimum
> supported CPU type is POWER9 or higher, and KVM is not selected.
>
> This saves 128kB kernel image size (90kB text) on powernv_defconfig
> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
...
> @@ -324,6 +330,7 @@ static inline void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
> }
> #endif /* !CONFIG_DEBUG_VM */
>
> +#if defined(CONFIG_PPC_RADIX_MMU) && defined(CONFIG_PPC_64S_HASH_MMU)
> static inline bool radix_enabled(void)
> {
> return mmu_has_feature(MMU_FTR_TYPE_RADIX);
> @@ -333,6 +340,27 @@ static inline bool early_radix_enabled(void)
> {
> return early_mmu_has_feature(MMU_FTR_TYPE_RADIX);
> }
> +#elif defined(CONFIG_PPC_64S_HASH_MMU)
> +static inline bool radix_enabled(void)
> +{
> + return false;
> +}
> +
> +static inline bool early_radix_enabled(void)
> +{
> + return false;
> +}
> +#else
> +static inline bool radix_enabled(void)
> +{
> + return true;
> +}
> +
> +static inline bool early_radix_enabled(void)
> +{
> + return true;
> +}
> +#endif
You don't need something that complex. You don't need to change that at all indeed, just have to
ensure that when CONFIG_PPC_64S_HASH_MMU is not selected you have MMU_FTR_TYPE_RADIX included in
MMU_FTRS_ALWAYS and voila.
>
> #ifdef CONFIG_STRICT_KERNEL_RWX
> static inline bool strict_kernel_rwx_enabled(void)
^ permalink raw reply
* Re: [RFC PATCH 5/6] powerpc/microwatt: select POWER9_CPU
From: Christophe Leroy @ 2021-08-28 9:50 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210827163410.1177154-6-npiggin@gmail.com>
Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
> Microwatt implements a subset of ISA v3.0 which is equivalent to
> the POWER9_CPU selection.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/configs/microwatt_defconfig | 1 +
> arch/powerpc/platforms/microwatt/Kconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
> index a08b739123da..bf5f2e5905eb 100644
> --- a/arch/powerpc/configs/microwatt_defconfig
> +++ b/arch/powerpc/configs/microwatt_defconfig
> @@ -14,6 +14,7 @@ CONFIG_EMBEDDED=y
> # CONFIG_COMPAT_BRK is not set
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_PPC64=y
> +CONFIG_POWER9_CPU=y
That shouldn't be needed in the defconfig because you select it below. You can use make
savedefconfig to confirm.
> # CONFIG_PPC_KUEP is not set
> # CONFIG_PPC_KUAP is not set
> CONFIG_CPU_LITTLE_ENDIAN=y
> diff --git a/arch/powerpc/platforms/microwatt/Kconfig b/arch/powerpc/platforms/microwatt/Kconfig
> index 823192e9d38a..e0ff2cfc1ca0 100644
> --- a/arch/powerpc/platforms/microwatt/Kconfig
> +++ b/arch/powerpc/platforms/microwatt/Kconfig
> @@ -2,6 +2,7 @@
> config PPC_MICROWATT
> depends on PPC_BOOK3S_64 && !SMP
> bool "Microwatt SoC platform"
> + select POWER9_CPU
> select PPC_XICS
> select PPC_ICS_NATIVE
> select PPC_ICP_NATIVE
>
^ permalink raw reply
* Re: [RFC PATCH 6/6] powerpc/microwatt: Stop building the hash MMU code
From: Christophe Leroy @ 2021-08-28 9:54 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210827163410.1177154-7-npiggin@gmail.com>
Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
> Microwatt is radix-only, so stop selecting the hash MMU code.
>
> This saves 20kB compressed dtbImage and 56kB vmlinux size.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/configs/microwatt_defconfig | 1 -
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> arch/powerpc/platforms/microwatt/Kconfig | 1 -
> 3 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
> index bf5f2e5905eb..6fbad42f9e3d 100644
> --- a/arch/powerpc/configs/microwatt_defconfig
> +++ b/arch/powerpc/configs/microwatt_defconfig
> @@ -26,7 +26,6 @@ CONFIG_PPC_MICROWATT=y
> # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
> CONFIG_CPU_FREQ=y
> CONFIG_HZ_100=y
> -# CONFIG_PPC_MEM_KEYS is not set
> # CONFIG_SECCOMP is not set
> # CONFIG_MQ_IOSCHED_KYBER is not set
> # CONFIG_COREDUMP is not set
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 9b90fc501ed4..b9acd6c68c81 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -371,6 +371,7 @@ config SPE
> config PPC_64S_HASH_MMU
> bool "Hash MMU Support"
> depends on PPC_BOOK3S_64
> + depends on !PPC_MICROWATT
Do we really want to start nit picking which platforms can select such or such option ?
Isn't it enough to get it off through the defconfig ?
Is PPC_MICROWATT mutually exclusive with other book3s64 configs ? Don't we build multiplatform kernels ?
> default y
> select PPC_MM_SLICES
> help
> diff --git a/arch/powerpc/platforms/microwatt/Kconfig b/arch/powerpc/platforms/microwatt/Kconfig
> index e0ff2cfc1ca0..4f0ce292a6ce 100644
> --- a/arch/powerpc/platforms/microwatt/Kconfig
> +++ b/arch/powerpc/platforms/microwatt/Kconfig
> @@ -6,7 +6,6 @@ config PPC_MICROWATT
> select PPC_XICS
> select PPC_ICS_NATIVE
> select PPC_ICP_NATIVE
> - select PPC_HASH_MMU_NATIVE if PPC_64S_HASH_MMU
> select PPC_UDBG_16550
> select ARCH_RANDOM
> help
>
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Christophe Leroy @ 2021-08-28 9:59 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210827163410.1177154-5-npiggin@gmail.com>
Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
> MMU code to be compiled out if radix is selected and the minimum
> supported CPU type is POWER9 or higher, and KVM is not selected.
>
> This saves 128kB kernel image size (90kB text) on powernv_defconfig
> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/book3s/64/mmu.h | 22 +++++-
> .../include/asm/book3s/64/tlbflush-hash.h | 7 ++
> arch/powerpc/include/asm/book3s/pgtable.h | 4 ++
> arch/powerpc/include/asm/mmu.h | 38 +++++++++--
> arch/powerpc/include/asm/mmu_context.h | 2 +
> arch/powerpc/include/asm/paca.h | 8 +++
> arch/powerpc/kernel/asm-offsets.c | 2 +
> arch/powerpc/kernel/dt_cpu_ftrs.c | 10 ++-
> arch/powerpc/kernel/entry_64.S | 4 +-
> arch/powerpc/kernel/exceptions-64s.S | 16 +++++
> arch/powerpc/kernel/mce.c | 2 +-
> arch/powerpc/kernel/mce_power.c | 10 ++-
> arch/powerpc/kernel/paca.c | 18 ++---
> arch/powerpc/kernel/process.c | 13 ++--
> arch/powerpc/kernel/prom.c | 2 +
> arch/powerpc/kernel/setup_64.c | 4 ++
> arch/powerpc/kexec/core_64.c | 4 +-
> arch/powerpc/kexec/ranges.c | 4 ++
> arch/powerpc/kvm/Kconfig | 1 +
> arch/powerpc/mm/book3s64/Makefile | 17 +++--
> arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
> arch/powerpc/mm/book3s64/hash_utils.c | 10 ---
> .../{hash_hugetlbpage.c => hugetlbpage.c} | 6 ++
> arch/powerpc/mm/book3s64/mmu_context.c | 16 +++++
> arch/powerpc/mm/book3s64/pgtable.c | 22 +++++-
> arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++
> arch/powerpc/mm/book3s64/slb.c | 16 -----
> arch/powerpc/mm/copro_fault.c | 2 +
> arch/powerpc/mm/fault.c | 17 +++++
> arch/powerpc/mm/pgtable.c | 10 ++-
> arch/powerpc/platforms/Kconfig.cputype | 20 +++++-
> arch/powerpc/platforms/cell/Kconfig | 1 +
> arch/powerpc/platforms/maple/Kconfig | 1 +
> arch/powerpc/platforms/microwatt/Kconfig | 2 +-
> arch/powerpc/platforms/pasemi/Kconfig | 1 +
> arch/powerpc/platforms/powermac/Kconfig | 1 +
> arch/powerpc/platforms/powernv/Kconfig | 2 +-
> arch/powerpc/platforms/powernv/idle.c | 2 +
> arch/powerpc/platforms/powernv/setup.c | 2 +
> arch/powerpc/platforms/pseries/lpar.c | 68 ++++++++++---------
> arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
> arch/powerpc/platforms/pseries/mobility.c | 6 ++
> arch/powerpc/platforms/pseries/ras.c | 4 ++
> arch/powerpc/platforms/pseries/reconfig.c | 2 +
> arch/powerpc/platforms/pseries/setup.c | 6 +-
> arch/powerpc/xmon/xmon.c | 8 ++-
> 47 files changed, 310 insertions(+), 111 deletions(-)
> rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (95%)
Whaou ! Huge patch.
Several places you should be able to use IS_ENABLED() or simply radix_enabled() instead of #ifdefs
and rely on GCC to opt out stuff when radix_enabled() folds into 'true'.
I may do more detailed comments later when I have time.
Christophe
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.14-7 tag
From: Michael Ellerman @ 2021-08-28 12:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lukas.bulwahn, linuxppc-dev, linux-kernel, npiggin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull two more powerpc fixes for 5.14:
The following changes since commit 9f7853d7609d59172eecfc5e7ccf503bc1b690bd:
powerpc/mm: Fix set_memory_*() against concurrent accesses (2021-08-19 09:41:54 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.14-7
for you to fetch changes up to 787c70f2f9990b5a197320152d2fc32cd8a6ad1a:
powerpc/64s: Fix scv implicit soft-mask table for relocated kernels (2021-08-20 22:35:18 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.14 #7
- Fix scv implicit soft-mask table for relocated (eg. kdump) kernels.
- Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK, which was disabled due to a typo.
Thanks to: Lukas Bulwahn, Nicholas Piggin, Daniel Axtens.
- ------------------------------------------------------------------
Lukas Bulwahn (1):
powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK
Nicholas Piggin (1):
powerpc/64s: Fix scv implicit soft-mask table for relocated kernels
arch/powerpc/kernel/exceptions-64s.S | 7 ++++---
arch/powerpc/platforms/Kconfig.cputype | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmEqL8QACgkQUevqPMjh
pYDvjQ//dYPmb8eTLrWTRXUy6vLnem+CuJv6gyLEG+7s6T8qZMSA2uvKr4zXAvgF
2QOAoVYWDth6blxjfHc5zqpdERhZHhOq0o2ofuJYGz1J/HAymvIohGFmiIwvOu5n
rPI8NMmsw61W35jJS7dgRr86b3rBwZSzRpDL14g+zQRRzuCqnBdOCA3Ixxn5JQ/F
D1AhyWL61IpVdg0Tz6FRU8s+VKYHh4Yr/CsozkFRMgqZZ2k3zs7aTcluyN8JhEta
BoqejJStrgRt2KOJPr3HXk5fHaoz/9AJn3lSauhnEPFR/Li2ChjkDZPd9KQysHI/
f56HfO/jRx3lY/qhHQ3HeGVJ8rsQrzEILj7KqL0KHwfQoqAhP3E2sut6oqZBFWii
HzfNl0vDrVkjBW7WDV/Y1hlGYaeiGt6DgXwh6wifek6JhMSABwyrd+Uoi9efG7sg
fOUl11VHvBHHQoT+h526urQrdSvgNn+M2iwjElK3LC+tDStNVZTxEiS/KtvpK1vC
I7f7CuwS+z3y4kPs2lwr1t0qQOnmOsvJP82+IDb7Tq4LJRgajyFlGdUEtMrpxZvP
whpFxWrxlQabX6QEr3CGYTGjbiYaGUCfWLkwhwpcftp7QcadjYko7u6nxIyOjI2G
8XG3+CMcPkNB4fSo4Ijt5upaTjhjl4JUGEenLHbyzdcixfj9Z9w=
=yPpX
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 6/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Vincent Guittot @ 2021-08-28 13:25 UTC (permalink / raw)
To: Ricardo Neri
Cc: Juri Lelli, Aubrey Li, Srikar Dronamraju, Ravi V. Shankar,
Peter Zijlstra (Intel), Ricardo Neri, Ben Segall,
Srinivas Pandruvada, Joel Fernandes (Google), Ingo Molnar,
Rafael J. Wysocki, Steven Rostedt, Mel Gorman, Len Brown,
Nicholas Piggin, Aubrey Li, Dietmar Eggemann, Tim Chen,
Quentin Perret, Daniel Bristot de Oliveira, linux-kernel,
linuxppc-dev
In-Reply-To: <20210827194503.GB14720@ranerica-svr.sc.intel.com>
On Fri, 27 Aug 2021 at 21:45, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
>
> On Fri, Aug 27, 2021 at 12:13:42PM +0200, Vincent Guittot wrote:
> > On Tue, 10 Aug 2021 at 16:41, Ricardo Neri
> > <ricardo.neri-calderon@linux.intel.com> wrote:
> > > @@ -9540,6 +9629,12 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> > > nr_running == 1)
> > > continue;
> > >
> > > + /* Make sure we only pull tasks from a CPU of lower priority */
> > > + if ((env->sd->flags & SD_ASYM_PACKING) &&
> > > + sched_asym_prefer(i, env->dst_cpu) &&
> > > + nr_running == 1)
> > > + continue;
> >
> > This really looks similar to the test above for SD_ASYM_CPUCAPACITY.
> > More generally speaking SD_ASYM_PACKING and SD_ASYM_CPUCAPACITY share
> > a lot of common policy and I wonder if at some point we could not
> > merge their behavior in LB
>
> I would like to confirm with you that you are not expecting this merge
> as part of this series, right?
Merging them will probably need more tests on both x86 and Arm so I
suppose that we could keep them separate for now
Regards,
Vincent
>
> Thanks and BR,
> Ricardo
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.14-7 tag
From: pr-tracker-bot @ 2021-08-28 18:47 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Linus Torvalds, linux-kernel, npiggin,
lukas.bulwahn
In-Reply-To: <874kb9g2k5.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 28 Aug 2021 22:46:02 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.14-7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9f73eacde73b105d722968e79d0f84fd5034a6f4
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Geoff Levand @ 2021-08-29 0:09 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <4f3113d1-b76e-a085-df2d-fd97d4b45faf@infradead.org>
Hi Christophe,
On 8/27/21 6:34 PM, Geoff Levand wrote:
> On 8/27/21 12:56 PM, Christophe JAILLET wrote:
>> It has *not* been compile tested because I don't have the needed
>> configuration or cross-compiler.
>
> The powerpc ppc64_defconfig has CONFIG_SPIDER_NET set. My
> tdd-builder Docker image has the needed gcc-powerpc-linux-gnu
> cross compiler to build ppc64_defconfig:
>
> https://hub.docker.com/r/glevand/tdd-builder
Just to follow up, I applied your patch to v5.14-rc7 and built
ppc64_defconfig. No warnings or errors were seen.
Thanks for your contribution.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Christophe Leroy @ 2021-08-29 8:01 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, geoff, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <60abc3d0c8b4ef8368a4d63326a25a5cb3cd218c.1630094078.git.christophe.jaillet@wanadoo.fr>
Le 27/08/2021 à 21:56, Christophe JAILLET a écrit :
> ---
> It has *not* been compile tested because I don't have the needed
> configuration or cross-compiler. However, the modification is completely
> mechanical and done by coccinelle.
All you need is at https://mirrors.edge.kernel.org/pub/tools/crosstool/
Christophe
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: patchwork-bot+netdevbpf @ 2021-08-29 10:00 UTC (permalink / raw)
To: Christophe JAILLET
Cc: geoff, netdev, kernel-janitors, linux-kernel, kuba, linuxppc-dev,
davem
In-Reply-To: <60abc3d0c8b4ef8368a4d63326a25a5cb3cd218c.1630094078.git.christophe.jaillet@wanadoo.fr>
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 27 Aug 2021 21:56:28 +0200 you wrote:
> In [1], Christoph Hellwig has proposed to remove the wrappers in
> include/linux/pci-dma-compat.h.
>
> Some reasons why this API should be removed have been given by Julia
> Lawall in [2].
>
> A coccinelle script has been used to perform the needed transformation
> Only relevant parts are given below.
>
> [...]
Here is the summary with links:
- net: spider_net: switch from 'pci_' to 'dma_' API
https://git.kernel.org/netdev/net-next/c/27d57f85102b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a555f645f92c58683d0a8d3315352a8d0ce8f80e
From: kernel test robot @ 2021-08-29 10:43 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: a555f645f92c58683d0a8d3315352a8d0ce8f80e Automatic merge of 'next' into merge (2021-08-23 23:59)
elapsed time: 6983m
configs tested: 182
configs skipped: 4
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
i386 randconfig-c001-20210827
powerpc randconfig-c003-20210827
arm omap2plus_defconfig
sparc64 alldefconfig
sparc sparc32_defconfig
mips lemote2f_defconfig
powerpc amigaone_defconfig
mips mtx1_defconfig
csky alldefconfig
powerpc mpc512x_defconfig
sh rts7751r2dplus_defconfig
sh sh7770_generic_defconfig
arm multi_v4t_defconfig
sh migor_defconfig
arm pxa168_defconfig
arm axm55xx_defconfig
powerpc pcm030_defconfig
mips rs90_defconfig
powerpc ppc40x_defconfig
arm ixp4xx_defconfig
arm spear13xx_defconfig
arc vdk_hs38_defconfig
arm spitz_defconfig
mips nlm_xlr_defconfig
arm integrator_defconfig
arm clps711x_defconfig
sh rsk7264_defconfig
mips tb0226_defconfig
powerpc pmac32_defconfig
mips ath79_defconfig
mips allmodconfig
alpha alldefconfig
powerpc ebony_defconfig
arm netwinder_defconfig
arm assabet_defconfig
arm imote2_defconfig
arm shannon_defconfig
arm pxa_defconfig
powerpc lite5200b_defconfig
mips vocore2_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a005-20210824
x86_64 randconfig-a006-20210824
x86_64 randconfig-a001-20210824
x86_64 randconfig-a003-20210824
x86_64 randconfig-a004-20210824
x86_64 randconfig-a002-20210824
i386 randconfig-a006-20210824
i386 randconfig-a001-20210824
i386 randconfig-a002-20210824
i386 randconfig-a005-20210824
i386 randconfig-a003-20210824
i386 randconfig-a004-20210824
x86_64 randconfig-a014-20210827
x86_64 randconfig-a015-20210827
x86_64 randconfig-a016-20210827
x86_64 randconfig-a013-20210827
x86_64 randconfig-a012-20210827
x86_64 randconfig-a011-20210827
x86_64 randconfig-a014-20210825
x86_64 randconfig-a015-20210825
x86_64 randconfig-a016-20210825
x86_64 randconfig-a013-20210825
x86_64 randconfig-a012-20210825
x86_64 randconfig-a011-20210825
i386 randconfig-a011-20210827
i386 randconfig-a016-20210827
i386 randconfig-a012-20210827
i386 randconfig-a014-20210827
i386 randconfig-a013-20210827
i386 randconfig-a015-20210827
i386 randconfig-a011-20210825
i386 randconfig-a016-20210825
i386 randconfig-a012-20210825
i386 randconfig-a014-20210825
i386 randconfig-a013-20210825
i386 randconfig-a015-20210825
arc randconfig-r043-20210825
riscv randconfig-r042-20210825
s390 randconfig-r044-20210825
arc randconfig-r043-20210824
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
s390 randconfig-c005-20210825
i386 randconfig-c001-20210825
arm randconfig-c002-20210825
riscv randconfig-c006-20210825
powerpc randconfig-c003-20210825
x86_64 randconfig-c007-20210825
mips randconfig-c004-20210825
i386 randconfig-c001-20210826
s390 randconfig-c005-20210826
arm randconfig-c002-20210826
riscv randconfig-c006-20210826
powerpc randconfig-c003-20210826
x86_64 randconfig-c007-20210826
mips randconfig-c004-20210826
i386 randconfig-a006-20210825
i386 randconfig-a001-20210825
i386 randconfig-a002-20210825
i386 randconfig-a005-20210825
i386 randconfig-a004-20210825
i386 randconfig-a003-20210825
i386 randconfig-a001-20210829
i386 randconfig-a006-20210829
i386 randconfig-a005-20210829
i386 randconfig-a004-20210829
i386 randconfig-a003-20210829
x86_64 randconfig-a014-20210824
x86_64 randconfig-a015-20210824
x86_64 randconfig-a016-20210824
x86_64 randconfig-a013-20210824
x86_64 randconfig-a012-20210824
x86_64 randconfig-a011-20210824
x86_64 randconfig-a005-20210827
x86_64 randconfig-a001-20210827
x86_64 randconfig-a006-20210827
x86_64 randconfig-a003-20210827
x86_64 randconfig-a004-20210827
x86_64 randconfig-a002-20210827
i386 randconfig-a011-20210824
i386 randconfig-a016-20210824
i386 randconfig-a012-20210824
i386 randconfig-a014-20210824
i386 randconfig-a013-20210824
i386 randconfig-a015-20210824
hexagon randconfig-r041-20210826
hexagon randconfig-r045-20210826
riscv randconfig-r042-20210826
s390 randconfig-r044-20210826
hexagon randconfig-r041-20210824
hexagon randconfig-r045-20210824
riscv randconfig-r042-20210824
s390 randconfig-r044-20210824
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Michael Ellerman @ 2021-08-29 12:25 UTC (permalink / raw)
To: Christophe Leroy, Christophe JAILLET, kou.ishizaki, geoff, davem,
kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <90220a35-bd0a-ccf3-91b1-c2a459c447e7@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 27/08/2021 à 21:56, Christophe JAILLET a écrit :
>> ---
>> It has *not* been compile tested because I don't have the needed
>> configuration or cross-compiler. However, the modification is completely
>> mechanical and done by coccinelle.
>
> All you need is at https://mirrors.edge.kernel.org/pub/tools/crosstool/
There's also some instructions here for using distro toolchains:
https://github.com/linuxppc/wiki/wiki/Building-powerpc-kernels
cheers
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Nathan Chancellor @ 2021-08-29 18:55 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <03166d569526be70214fe9370a7bad219d2f41c8.1625762907.git.christophe.leroy@csgroup.eu>
Hi Christophe,
On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
> This patch converts powerpc to the generic PTDUMP implementation.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
config [1] when booting up in QEMU with [2]:
[ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
[ 1.623058] Faulting instruction address: 0xc00000000045e5fc
[ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[ 1.625015] Modules linked in:
[ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
[ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
[ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
[ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
[ 1.628449] CFAR: c000000000518300 IRQMASK: 0
[ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
[ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
[ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
[ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
[ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
[ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
[ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
[ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
[ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
[ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
[ 1.635755] Call Trace:
[ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
[ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
[ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
[ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
[ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
[ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
[ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
[ 1.640597] Instruction dump:
[ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
[ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
[ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
[ 1.643220]
[ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
This is not compiler specific, I can reproduce it with GCC 11.2.0 and
binutils 2.37. If there is any additional information I can provide,
please let me know.
[1]: https://src.fedoraproject.org/rpms/kernel/raw/rawhide/f/kernel-ppc64le-fedora.config
[2]: https://github.com/ClangBuiltLinux/boot-utils
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Christophe Leroy @ 2021-08-29 19:11 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <YSvYFTSwP5EkXQZ0@Ryzen-9-3900X.localdomain>
Hi Nathan,
Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
> Hi Christophe,
>
> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>> This patch converts powerpc to the generic PTDUMP implementation.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
> config [1] when booting up in QEMU with [2]:
>
> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> [ 1.625015] Modules linked in:
> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
> [ 1.635755] Call Trace:
> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
> [ 1.640597] Instruction dump:
> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
> [ 1.643220]
> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
> binutils 2.37. If there is any additional information I can provide,
> please let me know.
Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
Thanks
Christophe
>
> [1]: https://src.fedoraproject.org/rpms/kernel/raw/rawhide/f/kernel-ppc64le-fedora.config
> [2]: https://github.com/ClangBuiltLinux/boot-utils
>
> Cheers,
> Nathan
>
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Nathan Chancellor @ 2021-08-29 21:39 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <5c479866-f31a-3579-9d71-357c85b777d0@csgroup.eu>
On Sun, Aug 29, 2021 at 09:11:47PM +0200, Christophe Leroy wrote:
> Hi Nathan,
>
> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
> > Hi Christophe,
> >
> > On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
> > > This patch converts powerpc to the generic PTDUMP implementation.
> > >
> > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >
> > This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
> > GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
> > config [1] when booting up in QEMU with [2]:
> >
> > [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
> > [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
> > [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
> > [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> > [ 1.625015] Modules linked in:
> > [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
> > [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
> > [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
> > [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
> > [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
> > [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
> > [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
> > [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
> > [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
> > [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
> > [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
> > [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
> > [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
> > [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
> > [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
> > [ 1.635755] Call Trace:
> > [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
> > [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
> > [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
> > [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
> > [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
> > [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
> > [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
> > [ 1.640597] Instruction dump:
> > [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
> > [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
> > [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
> > [ 1.643220]
> > [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >
> > This is not compiler specific, I can reproduce it with GCC 11.2.0 and
> > binutils 2.37. If there is any additional information I can provide,
> > please let me know.
>
> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
Sure thing!
Disassembly of mm/pagewalk.o: https://gist.github.com/2cc2cadc598fe55b0f5cea0d75e89186
vmlinux binary (zstd compressed, 123MB): https://1drv.ms/u/s!AsQNYeB-IEbqjjai5EiHUBiPYzI3?e=kqUwpN
Cheers,
Nathan
^ permalink raw reply
* Re: [RFC PATCH 6/6] powerpc/microwatt: Stop building the hash MMU code
From: Michael Ellerman @ 2021-08-30 3:24 UTC (permalink / raw)
To: Christophe Leroy, Nicholas Piggin, linuxppc-dev
In-Reply-To: <1d1484fe-70db-bafc-016f-29671e941bc8@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Microwatt is radix-only, so stop selecting the hash MMU code.
>>
>> This saves 20kB compressed dtbImage and 56kB vmlinux size.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/configs/microwatt_defconfig | 1 -
>> arch/powerpc/platforms/Kconfig.cputype | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 1 -
>> 3 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>> index bf5f2e5905eb..6fbad42f9e3d 100644
>> --- a/arch/powerpc/configs/microwatt_defconfig
>> +++ b/arch/powerpc/configs/microwatt_defconfig
>> @@ -26,7 +26,6 @@ CONFIG_PPC_MICROWATT=y
>> # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
>> CONFIG_CPU_FREQ=y
>> CONFIG_HZ_100=y
>> -# CONFIG_PPC_MEM_KEYS is not set
>> # CONFIG_SECCOMP is not set
>> # CONFIG_MQ_IOSCHED_KYBER is not set
>> # CONFIG_COREDUMP is not set
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>> index 9b90fc501ed4..b9acd6c68c81 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -371,6 +371,7 @@ config SPE
>> config PPC_64S_HASH_MMU
>> bool "Hash MMU Support"
>> depends on PPC_BOOK3S_64
>> + depends on !PPC_MICROWATT
>
> Do we really want to start nit picking which platforms can select such or such option ?
> Isn't it enough to get it off through the defconfig ?
>
> Is PPC_MICROWATT mutually exclusive with other book3s64 configs ? Don't we build multiplatform kernels ?
Yeah that belongs in the microwatt defconfig, not as a forced exclusion
in Kconfig.
cheers
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-08-30 6:51 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <3b419b53-02b8-1a52-2f22-7b8ca49c4460@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:34 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
>> MMU code to be compiled out if radix is selected and the minimum
>> supported CPU type is POWER9 or higher, and KVM is not selected.
>>
>> This saves 128kB kernel image size (90kB text) on powernv_defconfig
>> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>
> ...
>
>> @@ -324,6 +330,7 @@ static inline void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
>> }
>> #endif /* !CONFIG_DEBUG_VM */
>>
>> +#if defined(CONFIG_PPC_RADIX_MMU) && defined(CONFIG_PPC_64S_HASH_MMU)
>> static inline bool radix_enabled(void)
>> {
>> return mmu_has_feature(MMU_FTR_TYPE_RADIX);
>> @@ -333,6 +340,27 @@ static inline bool early_radix_enabled(void)
>> {
>> return early_mmu_has_feature(MMU_FTR_TYPE_RADIX);
>> }
>> +#elif defined(CONFIG_PPC_64S_HASH_MMU)
>> +static inline bool radix_enabled(void)
>> +{
>> + return false;
>> +}
>> +
>> +static inline bool early_radix_enabled(void)
>> +{
>> + return false;
>> +}
>> +#else
>> +static inline bool radix_enabled(void)
>> +{
>> + return true;
>> +}
>> +
>> +static inline bool early_radix_enabled(void)
>> +{
>> + return true;
>> +}
>> +#endif
>
> You don't need something that complex. You don't need to change that at all indeed, just have to
> ensure that when CONFIG_PPC_64S_HASH_MMU is not selected you have MMU_FTR_TYPE_RADIX included in
> MMU_FTRS_ALWAYS and voila.
Yeah I had that as a later patch that fixes up the MMU ftrs for 64s
which does that, I think was required before some of your patches were
upstreamed.
But looks like it is now trivial so I should just pull that in here.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-08-30 6:55 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <da2863dc-f8d9-f58b-0d52-7e1bd668718c@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:59 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
>> MMU code to be compiled out if radix is selected and the minimum
>> supported CPU type is POWER9 or higher, and KVM is not selected.
>>
>> This saves 128kB kernel image size (90kB text) on powernv_defconfig
>> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/book3s/64/mmu.h | 22 +++++-
>> .../include/asm/book3s/64/tlbflush-hash.h | 7 ++
>> arch/powerpc/include/asm/book3s/pgtable.h | 4 ++
>> arch/powerpc/include/asm/mmu.h | 38 +++++++++--
>> arch/powerpc/include/asm/mmu_context.h | 2 +
>> arch/powerpc/include/asm/paca.h | 8 +++
>> arch/powerpc/kernel/asm-offsets.c | 2 +
>> arch/powerpc/kernel/dt_cpu_ftrs.c | 10 ++-
>> arch/powerpc/kernel/entry_64.S | 4 +-
>> arch/powerpc/kernel/exceptions-64s.S | 16 +++++
>> arch/powerpc/kernel/mce.c | 2 +-
>> arch/powerpc/kernel/mce_power.c | 10 ++-
>> arch/powerpc/kernel/paca.c | 18 ++---
>> arch/powerpc/kernel/process.c | 13 ++--
>> arch/powerpc/kernel/prom.c | 2 +
>> arch/powerpc/kernel/setup_64.c | 4 ++
>> arch/powerpc/kexec/core_64.c | 4 +-
>> arch/powerpc/kexec/ranges.c | 4 ++
>> arch/powerpc/kvm/Kconfig | 1 +
>> arch/powerpc/mm/book3s64/Makefile | 17 +++--
>> arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
>> arch/powerpc/mm/book3s64/hash_utils.c | 10 ---
>> .../{hash_hugetlbpage.c => hugetlbpage.c} | 6 ++
>> arch/powerpc/mm/book3s64/mmu_context.c | 16 +++++
>> arch/powerpc/mm/book3s64/pgtable.c | 22 +++++-
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++
>> arch/powerpc/mm/book3s64/slb.c | 16 -----
>> arch/powerpc/mm/copro_fault.c | 2 +
>> arch/powerpc/mm/fault.c | 17 +++++
>> arch/powerpc/mm/pgtable.c | 10 ++-
>> arch/powerpc/platforms/Kconfig.cputype | 20 +++++-
>> arch/powerpc/platforms/cell/Kconfig | 1 +
>> arch/powerpc/platforms/maple/Kconfig | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 2 +-
>> arch/powerpc/platforms/pasemi/Kconfig | 1 +
>> arch/powerpc/platforms/powermac/Kconfig | 1 +
>> arch/powerpc/platforms/powernv/Kconfig | 2 +-
>> arch/powerpc/platforms/powernv/idle.c | 2 +
>> arch/powerpc/platforms/powernv/setup.c | 2 +
>> arch/powerpc/platforms/pseries/lpar.c | 68 ++++++++++---------
>> arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
>> arch/powerpc/platforms/pseries/mobility.c | 6 ++
>> arch/powerpc/platforms/pseries/ras.c | 4 ++
>> arch/powerpc/platforms/pseries/reconfig.c | 2 +
>> arch/powerpc/platforms/pseries/setup.c | 6 +-
>> arch/powerpc/xmon/xmon.c | 8 ++-
>> 47 files changed, 310 insertions(+), 111 deletions(-)
>> rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (95%)
>
> Whaou ! Huge patch.
>
> Several places you should be able to use IS_ENABLED() or simply radix_enabled() instead of #ifdefs
> and rely on GCC to opt out stuff when radix_enabled() folds into 'true'.
A lot of it couldn't be done because of data structures but I'm sure I
missed a lot. I will go over it again.
> I may do more detailed comments later when I have time.
Very much appreciated, but let me send out another version before you
get the fine toothed comb out so I don't waste too much of your time.
If there are no objections to the idea from a high level.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 5/6] powerpc/microwatt: select POWER9_CPU
From: Nicholas Piggin @ 2021-08-30 6:56 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <ee10053e-f007-719a-9ab2-a14388c9af9d@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:50 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Microwatt implements a subset of ISA v3.0 which is equivalent to
>> the POWER9_CPU selection.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/configs/microwatt_defconfig | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>> index a08b739123da..bf5f2e5905eb 100644
>> --- a/arch/powerpc/configs/microwatt_defconfig
>> +++ b/arch/powerpc/configs/microwatt_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_EMBEDDED=y
>> # CONFIG_COMPAT_BRK is not set
>> # CONFIG_SLAB_MERGE_DEFAULT is not set
>> CONFIG_PPC64=y
>> +CONFIG_POWER9_CPU=y
>
> That shouldn't be needed in the defconfig because you select it below. You can use make
> savedefconfig to confirm.
Good point.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 6/6] powerpc/microwatt: Stop building the hash MMU code
From: Nicholas Piggin @ 2021-08-30 6:58 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev, Michael Ellerman
In-Reply-To: <87y28jehrt.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of August 30, 2021 1:24 pm:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>>> Microwatt is radix-only, so stop selecting the hash MMU code.
>>>
>>> This saves 20kB compressed dtbImage and 56kB vmlinux size.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/configs/microwatt_defconfig | 1 -
>>> arch/powerpc/platforms/Kconfig.cputype | 1 +
>>> arch/powerpc/platforms/microwatt/Kconfig | 1 -
>>> 3 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>>> index bf5f2e5905eb..6fbad42f9e3d 100644
>>> --- a/arch/powerpc/configs/microwatt_defconfig
>>> +++ b/arch/powerpc/configs/microwatt_defconfig
>>> @@ -26,7 +26,6 @@ CONFIG_PPC_MICROWATT=y
>>> # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
>>> CONFIG_CPU_FREQ=y
>>> CONFIG_HZ_100=y
>>> -# CONFIG_PPC_MEM_KEYS is not set
>>> # CONFIG_SECCOMP is not set
>>> # CONFIG_MQ_IOSCHED_KYBER is not set
>>> # CONFIG_COREDUMP is not set
>>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>>> index 9b90fc501ed4..b9acd6c68c81 100644
>>> --- a/arch/powerpc/platforms/Kconfig.cputype
>>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>>> @@ -371,6 +371,7 @@ config SPE
>>> config PPC_64S_HASH_MMU
>>> bool "Hash MMU Support"
>>> depends on PPC_BOOK3S_64
>>> + depends on !PPC_MICROWATT
>>
>> Do we really want to start nit picking which platforms can select such or such option ?
>> Isn't it enough to get it off through the defconfig ?
>>
>> Is PPC_MICROWATT mutually exclusive with other book3s64 configs ? Don't we build multiplatform kernels ?
>
> Yeah that belongs in the microwatt defconfig, not as a forced exclusion
> in Kconfig.
Okay I'll fix that up. In that case the select POWER9 should not be in
Kconfig but just defconfig too. Which is fine, it just means oldconfig
won't change it.
Thanks,
Nick
^ 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