* [PATCH] powerpc/Makefile: Add ppc32/ppc64_randconfig targets
From: Michael Ellerman @ 2021-04-28 13:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: masahiroy, rdunlap
Make it easier to generate a 32 or 64-bit specific randconfig.
Requested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Makefile | 10 ++++++++++
arch/powerpc/configs/32-bit.config | 1 +
arch/powerpc/configs/64-bit.config | 1 +
3 files changed, 12 insertions(+)
create mode 100644 arch/powerpc/configs/32-bit.config
create mode 100644 arch/powerpc/configs/64-bit.config
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3212d076ac6a..712c5e8768ce 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -376,6 +376,16 @@ PHONY += ppc64_book3e_allmodconfig
$(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
-f $(srctree)/Makefile allmodconfig
+PHONY += ppc32_randconfig
+ppc32_randconfig:
+ $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \
+ -f $(srctree)/Makefile randconfig
+
+PHONY += ppc64_randconfig
+ppc64_randconfig:
+ $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \
+ -f $(srctree)/Makefile randconfig
+
define archhelp
@echo '* zImage - Build default images selected by kernel config'
@echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
diff --git a/arch/powerpc/configs/32-bit.config b/arch/powerpc/configs/32-bit.config
new file mode 100644
index 000000000000..ad6546850c68
--- /dev/null
+++ b/arch/powerpc/configs/32-bit.config
@@ -0,0 +1 @@
+# CONFIG_PPC64 is not set
diff --git a/arch/powerpc/configs/64-bit.config b/arch/powerpc/configs/64-bit.config
new file mode 100644
index 000000000000..0fe6406929e2
--- /dev/null
+++ b/arch/powerpc/configs/64-bit.config
@@ -0,0 +1 @@
+CONFIG_PPC64=y
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v4 2/2] of: net: fix of_get_mac_addr_nvmem() for non-platform devices
From: Michael Walle @ 2021-04-28 8:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Lunn, Paul Mackerras, Rafał Miłecki,
Nobuhiro Iwamatsu, moderated list:ARM/STM32 ARCHITECTURE,
Jerome Brunet, Neil Armstrong, Michal Simek, Jose Abreu,
NXP Linux Team, Mark Lee, Vadym Kochan, Sascha Hauer,
Lorenzo Bianconi, linux-omap, Greg Kroah-Hartman, linux-wireless,
linux-kernel, Pengutronix Kernel Team, Vladimir Oltean,
Claudiu Beznea, Jérôme Pouiller, Kunihiko Hayashi,
Chris Snook, Frank Rowand, Gregory Clement, Madalin Bucur,
Martin Blumenstingl, Murali Karicheri, Yisen Zhuang,
Alexandre Torgue, Wingman Kwok, Sean Wang, Maxime Ripard,
Claudiu Manoil, open list:ARM/Amlogic Meson..., Kalle Valo,
Mirko Lindner, Fugang Duan, Bryan Whitehead,
QCA ath9k Development, Microchip Linux Driver Support,
Taras Chornyi, Maxime Coquelin, Kevin Hilman, Heiner Kallweit,
Andreas Larsson, Giuseppe Cavallaro, Fabio Estevam,
Stanislaw Gruszka, Florian Fainelli, linux-staging, Chen-Yu Tsai,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, linux-arm-kernel,
Grygorii Strashko, Byungho An, Radhey Shyam Pandey,
Vladimir Zapolskiy, John Crispin, Salil Mehta, Sergei Shtylyov,
linux-oxnas, Shawn Guo, David S . Miller, Helmut Schaa,
Thomas Petazzoni, open list:MEDIA DRIVERS FOR RENESAS - FCP,
Ryder Lee, Russell King, Hauke Mehrtens, Jakub Kicinski,
Vivien Didelot, Sunil Goutham, Sebastian Hesselbarth, devicetree,
Rob Herring, moderated list:ARM/Mediatek SoC support,
Matthias Brugger, Jernej Skrabec, netdev, Nicolas Ferre, Li Yang,
Stephen Hemminger, Vinod Koul, Joyce Ooi, linuxppc-dev,
Felix Fietkau
In-Reply-To: <3677398ebb77f334abb4899770db633d9658fe82.camel@kernel.crashing.org>
Am 2021-04-27 01:44, schrieb Benjamin Herrenschmidt:
> On Mon, 2021-04-26 at 12:54 +0200, Michael Walle wrote:
>> (2) What do you think of eth_get_mac_address(ndev). That is, the
>
> Not sure what you mean, eth_platform_get_mac_address() takes the
> address as an argument. I think what you want is a consolidated
> nvmem_get_mac_address + eth_platform_get_mac_address that takes a
> device, which would have no requirement of the bus_type at all.
Sure. What I meant was the following:
eth_get_mac_address(struct net_device *ndev)
vs.
eth_get_mac_address(struct device *dev, u8 *mac_buf)
The first would assume the destination is ndev->dev_addr (which
is true for most of the calls, but not all).
-michael
^ permalink raw reply
* Re: [PATCH] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
From: Gautham R Shenoy @ 2021-04-28 11:34 UTC (permalink / raw)
To: Michal Suchánek
Cc: Gautham R Shenoy, linux-pm, Aneesh Kumar K.V, Daniel Lezcano,
Rafael J. Wysocki, joedecke, linuxppc-dev
In-Reply-To: <20210428080326.GL6564@kitsune.suse.cz>
Hello Michal,
On Wed, Apr 28, 2021 at 10:03:26AM +0200, Michal Suchánek wrote:
> >
> That's a nice detailed explanation. Maybe you could summarize it in the
> commit message so that people looking at the patch in the future can
> tell where the value comes from.
Sure, I will do that and send a v2 with the updated commit message.
>
> Thanks
>
> Michal
^ permalink raw reply
* Re: [PATCH v13 06/14] mm: HUGE_VMAP arch support cleanup
From: Christophe Leroy @ 2021-04-28 8:32 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, x86, H. Peter Anvin, Will Deacon, Catalin Marinas,
Jonathan Cameron, linux-kernel, Christoph Hellwig, Ingo Molnar,
Borislav Petkov, Ding Tianhong, Thomas Gleixner, Rick Edgecombe,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210317062402.533919-7-npiggin@gmail.com>
Le 17/03/2021 à 07:23, Nicholas Piggin a écrit :
> This changes the awkward approach where architectures provide init
> functions to determine which levels they can provide large mappings for,
> to one where the arch is queried for each call.
>
> This removes code and indirection, and allows constant-folding of dead
> code for unsupported levels.
>
> This also adds a prot argument to the arch query. This is unused
> currently but could help with some architectures (e.g., some powerpc
> processors can't map uncacheable memory with large pages).
>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Reviewed-by: Ding Tianhong <dingtianhong@huawei.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/arm64/include/asm/vmalloc.h | 8 ++
> arch/arm64/mm/mmu.c | 10 +--
> arch/powerpc/include/asm/vmalloc.h | 8 ++
> arch/powerpc/mm/book3s64/radix_pgtable.c | 8 +-
> arch/x86/include/asm/vmalloc.h | 7 ++
> arch/x86/mm/ioremap.c | 12 +--
> include/linux/io.h | 9 ---
> include/linux/vmalloc.h | 6 ++
> init/main.c | 1 -
> mm/debug_vm_pgtable.c | 4 +-
> mm/ioremap.c | 94 ++++++++++--------------
> 11 files changed, 87 insertions(+), 80 deletions(-)
>
> diff --git a/mm/ioremap.c b/mm/ioremap.c
> index 3f4d36f9745a..3264d0203785 100644
> --- a/mm/ioremap.c
> +++ b/mm/ioremap.c
> @@ -16,49 +16,16 @@
> #include "pgalloc-track.h"
>
> #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> -static int __read_mostly ioremap_p4d_capable;
> -static int __read_mostly ioremap_pud_capable;
> -static int __read_mostly ioremap_pmd_capable;
> -static int __read_mostly ioremap_huge_disabled;
> +static bool __ro_after_init iomap_max_page_shift = PAGE_SHIFT;
Must be an int, not a bool.
>
> static int __init set_nohugeiomap(char *str)
> {
> - ioremap_huge_disabled = 1;
> + iomap_max_page_shift = P4D_SHIFT;
> return 0;
> }
> early_param("nohugeiomap", set_nohugeiomap);
> -
> -void __init ioremap_huge_init(void)
> -{
> - if (!ioremap_huge_disabled) {
> - if (arch_ioremap_p4d_supported())
> - ioremap_p4d_capable = 1;
> - if (arch_ioremap_pud_supported())
> - ioremap_pud_capable = 1;
> - if (arch_ioremap_pmd_supported())
> - ioremap_pmd_capable = 1;
> - }
> -}
> -
> -static inline int ioremap_p4d_enabled(void)
> -{
> - return ioremap_p4d_capable;
> -}
> -
> -static inline int ioremap_pud_enabled(void)
> -{
> - return ioremap_pud_capable;
> -}
> -
> -static inline int ioremap_pmd_enabled(void)
> -{
> - return ioremap_pmd_capable;
> -}
> -
> -#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
> -static inline int ioremap_p4d_enabled(void) { return 0; }
> -static inline int ioremap_pud_enabled(void) { return 0; }
> -static inline int ioremap_pmd_enabled(void) { return 0; }
> +#else /* CONFIG_HAVE_ARCH_HUGE_VMAP */
> +static const bool iomap_max_page_shift = PAGE_SHIFT;
> #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>
> static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
Christophe
^ permalink raw reply
* Re: [PATCH v13 06/14] mm: HUGE_VMAP arch support cleanup
From: Christophe Leroy @ 2021-04-28 8:34 UTC (permalink / raw)
To: Nicholas Piggin, linux-mm, Andrew Morton
Cc: linux-arch, x86, H. Peter Anvin, Will Deacon, Catalin Marinas,
Jonathan Cameron, linux-kernel, Christoph Hellwig, Ingo Molnar,
Borislav Petkov, Ding Tianhong, Thomas Gleixner, Rick Edgecombe,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <303a93df-6b32-1b3e-d293-b569e1a4b03e@csgroup.eu>
Le 28/04/2021 à 10:32, Christophe Leroy a écrit :
>
>
> Le 17/03/2021 à 07:23, Nicholas Piggin a écrit :
>> This changes the awkward approach where architectures provide init
>> functions to determine which levels they can provide large mappings for,
>> to one where the arch is queried for each call.
>>
>> This removes code and indirection, and allows constant-folding of dead
>> code for unsupported levels.
>>
>> This also adds a prot argument to the arch query. This is unused
>> currently but could help with some architectures (e.g., some powerpc
>> processors can't map uncacheable memory with large pages).
>>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: x86@kernel.org
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Reviewed-by: Ding Tianhong <dingtianhong@huawei.com>
>> Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/arm64/include/asm/vmalloc.h | 8 ++
>> arch/arm64/mm/mmu.c | 10 +--
>> arch/powerpc/include/asm/vmalloc.h | 8 ++
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 8 +-
>> arch/x86/include/asm/vmalloc.h | 7 ++
>> arch/x86/mm/ioremap.c | 12 +--
>> include/linux/io.h | 9 ---
>> include/linux/vmalloc.h | 6 ++
>> init/main.c | 1 -
>> mm/debug_vm_pgtable.c | 4 +-
>> mm/ioremap.c | 94 ++++++++++--------------
>> 11 files changed, 87 insertions(+), 80 deletions(-)
>>
>
>> diff --git a/mm/ioremap.c b/mm/ioremap.c
>> index 3f4d36f9745a..3264d0203785 100644
>> --- a/mm/ioremap.c
>> +++ b/mm/ioremap.c
>> @@ -16,49 +16,16 @@
>> #include "pgalloc-track.h"
>> #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> -static int __read_mostly ioremap_p4d_capable;
>> -static int __read_mostly ioremap_pud_capable;
>> -static int __read_mostly ioremap_pmd_capable;
>> -static int __read_mostly ioremap_huge_disabled;
>> +static bool __ro_after_init iomap_max_page_shift = PAGE_SHIFT;
>
> Must be an int, not a bool.
And the initial value seems wrong. Should be P4D_SHIFT ?
>
>> static int __init set_nohugeiomap(char *str)
>> {
>> - ioremap_huge_disabled = 1;
>> + iomap_max_page_shift = P4D_SHIFT;
And PAGE_SHIFT here when NO hugeiomap ?
>> return 0;
>> }
>> early_param("nohugeiomap", set_nohugeiomap);
Christophe
^ permalink raw reply
* Re: [PATCH v5 05/16] swiotlb: Add restricted DMA pool initialization
From: Steven Price @ 2021-04-28 9:50 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, lkml, grant.likely, paulus, Will Deacon, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, xypron.glpk,
Joerg Roedel, Rafael J . Wysocki, Christoph Hellwig,
Bartosz Golaszewski, bskeggs, linux-pci, xen-devel,
Thierry Reding, intel-gfx, matthew.auld, linux-devicetree,
Jianxiong Gao, Daniel Vetter, Konrad Rzeszutek Wilk,
maarten.lankhorst, airlied, Dan Williams, linuxppc-dev,
jani.nikula, Nicolas Boichat, rodrigo.vivi, Bjorn Helgaas,
boris.ostrovsky, Andy Shevchenko, jgross, chris, nouveau, Greg KH,
Randy Dunlap, Frank Rowand, Tomasz Figa,
list@263.net:IOMMU DRIVERS, Jim Quinlan, Robin Murphy, bauerman
In-Reply-To: <CALiNf2_tffc65PhLxCr3-+gmVYKGO2HjYiJVkBNa5U5HYdi9pg@mail.gmail.com>
On 26/04/2021 17:37, Claire Chang wrote:
> On Fri, Apr 23, 2021 at 7:34 PM Steven Price <steven.price@arm.com> wrote:
[...]
>>
>> But even then if it's not and we have the situation where debugfs==NULL
>> then the debugfs_create_dir() here will cause a subsequent attempt in
>> swiotlb_create_debugfs() to fail (directory already exists) leading to
>> mem->debugfs being assigned an error value. I suspect the creation of
>> the debugfs directory needs to be separated from io_tlb_default_mem
>> being set.
>
> debugfs creation should move into the if (!mem) {...} above to avoid
> duplication.
> I think having a separated struct dentry pointer for the default
> debugfs should be enough?
>
> if (!debugfs)
> debugfs = debugfs_create_dir("swiotlb", NULL);
> swiotlb_create_debugfs(mem, rmem->name, debugfs);
Yes that looks like a good solution to me. Although I'd name the
variable something a bit more descriptive than just "debugfs" e.g.
"debugfs_dir" or "debugfs_root".
Thanks,
Steve
^ permalink raw reply
* [PATCH v3] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-28 9:47 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is caught by the kernel, but the memory's node is updated because
there is no way to move a memory block between nodes.
If later a memory block is added or removed, drmem_update_dt() is called
and it is overwriting the DT node to match the added or removed LMB. But
the LMB's associativity node has not been updated after the DT node update
and thus the node is overwritten by the Linux's topology instead of the
hypervisor one.
Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
updated to force an update of the LMB's associativity.
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
V3:
- Check rd->dn->name instead of rd->dn->full_name
V2:
- Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
introducing a new hook mechanism.
---
arch/powerpc/include/asm/drmem.h | 1 +
arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
.../platforms/pseries/hotplug-memory.c | 4 +++
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index bf2402fed3e0..4265d5e95c2c 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -111,6 +111,7 @@ int drmem_update_dt(void);
int __init
walk_drmem_lmbs_early(unsigned long node, void *data,
int (*func)(struct drmem_lmb *, const __be32 **, void *));
+void drmem_update_lmbs(struct property *prop);
#endif
static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 9af3832c9d8d..f0a6633132af 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
return ret;
}
+/*
+ * Update the LMB associativity index.
+ */
+static int update_lmb(struct drmem_lmb *updated_lmb,
+ __maybe_unused const __be32 **usm,
+ __maybe_unused void *data)
+{
+ struct drmem_lmb *lmb;
+
+ /*
+ * Brut force there may be better way to fetch the LMB
+ */
+ for_each_drmem_lmb(lmb) {
+ if (lmb->drc_index != updated_lmb->drc_index)
+ continue;
+
+ lmb->aa_index = updated_lmb->aa_index;
+ break;
+ }
+ return 0;
+}
+
+/*
+ * Update the LMB associativity index.
+ *
+ * This needs to be called when the hypervisor is updating the
+ * dynamic-reconfiguration-memory node property.
+ */
+void drmem_update_lmbs(struct property *prop)
+{
+ if (!strcmp(prop->name, "ibm,dynamic-memory"))
+ __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
+ else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
+ __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
+}
#endif
static int init_drmem_lmb_size(struct device_node *dn)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8377f1f7c78e..672ffbee2e78 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
case OF_RECONFIG_DETACH_NODE:
err = pseries_remove_mem_node(rd->dn);
break;
+ case OF_RECONFIG_UPDATE_PROPERTY:
+ if (!strcmp(rd->dn->name,
+ "ibm,dynamic-reconfiguration-memory"))
+ drmem_update_lmbs(rd->prop);
}
return notifier_from_errno(err);
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
From: Michal Suchánek @ 2021-04-28 8:03 UTC (permalink / raw)
To: Gautham R Shenoy
Cc: linux-pm, Daniel Lezcano, Rafael J. Wysocki, joedecke,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20210428055848.GA6675@in.ibm.com>
On Wed, Apr 28, 2021 at 11:28:48AM +0530, Gautham R Shenoy wrote:
> Hello Michal,
>
> On Sun, Apr 25, 2021 at 01:07:14PM +0200, Michal Suchánek wrote:
> > On Sat, Apr 24, 2021 at 01:07:16PM +0530, Vaidyanathan Srinivasan wrote:
> > > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 20:42:16]:
> > >
> > > > On Fri, Apr 23, 2021 at 11:59:30PM +0530, Vaidyanathan Srinivasan wrote:
> > > > > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 19:45:05]:
> > > > >
> > > > > > On Fri, Apr 23, 2021 at 09:29:39PM +0530, Vaidyanathan Srinivasan wrote:
> > > > > > > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 09:35:51]:
> > > > > > >
> > > > > > > > On Thu, Apr 22, 2021 at 08:37:29PM +0530, Gautham R. Shenoy wrote:
> > > > > > > > > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> > > > > > > > >
> > > > > > > > > Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> > > > > > > > > CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> > > > > > > > > of the Extended CEDE states advertised by the platform
> > > > > > > > >
> > > > > > > > > On some of the POWER9 LPARs, the older firmwares advertise a very low
> > > > > > > > > value of 2us for CEDE1 exit latency on a Dedicated LPAR. However the
> > > > > > > > Can you be more specific about 'older firmwares'?
> > > > > > >
> > > > > > > Hi Michal,
> > > > > > >
> > > > > > > This is POWER9 vs POWER10 difference, not really an obsolete FW. The
> > > > > > > key idea behind the original patch was to make the H_CEDE latency and
> > > > > > > hence target residency come from firmware instead of being decided by
> > > > > > > the kernel. The advantage is such that, different type of systems in
> > > > > > > POWER10 generation can adjust this value and have an optimal H_CEDE
> > > > > > > entry criteria which balances good single thread performance and
> > > > > > > wakeup latency. Further we can have additional H_CEDE state to feed
> > > > > > > into the cpuidle.
> > > > > >
> > > > > > So all POWER9 machines are affected by the firmware bug where firmware
> > > > > > reports CEDE1 exit latency of 2us and the real latency is 5us which
> > > > > > causes the kernel to prefer CEDE1 too much when relying on the values
> > > > > > supplied by the firmware. It is not about 'older firmware'.
> > > > >
> > > > > Correct. All POWER9 systems running Linux as guest LPARs will see
> > > > > extra usage of CEDE idle state, but not baremetal (PowerNV).
> > > > >
> > > > > The correct definition of the bug or miss-match in expectation is that
> > > > > firmware reports wakeup latency from a core/thread wakeup timing, but
> > > > > not end-to-end time from sending a wakeup event like an IPI using
> > > > > H_calls and receiving the events on the target. Practically there are
> > > > > few extra micro-seconds needed after deciding to wakeup a target
> > > > > core/thread to getting the target to start executing instructions
> > > > > within the LPAR instance.
> > > >
> > > > Thanks for the detailed explanation.
> > > >
> > > > Maybe just adding a few microseconds to the reported time would be a
> > > > more reasonable workaround than using a blanket fixed value then.
> > >
> > > Yes, that is an option. But that may only reduce the difference
> > > between existing kernel and new kernel unless we make it the same
> > > number. Further we are fixing this in P10 and hence we will have to
> > > add "if(P9) do the compensation" and otherwise take it as is. That
> > > would not be elegant. Given that our goal for P9 platform is to not
> > > introduce changes in H_CEDE entry behaviour, we arrived at this
> > > approach (this small patch) and this also makes it easy to backport to
> > > various distro products.
> >
> > I don't see how this is more elegent.
> >
> > The current patch is
> >
> > if(p9)
> > use fixed value
> >
> > the suggested patch is
> >
> > if(p9)
> > apply compensation
>
>
> We could do that, however, from the recent measurements the default
> value is closer to the latency value measured using an IPI.
>
> As Vaidy described earlier, on POWER9 and prior platforms, the wakeup
> latency advertized by the PHYP hypervisor corresponds to the latency
> required to wakeup from the underlying hardware idle state (Nap in
> POWER8 and stop0/1/2 on POWER9) into the hypervisor. That's 2us on
> POWER9.
>
> We need to apply two kinds of compensation,
>
> 1. Compensation for the time taken to transition the CPU from the
> Hypervisor into the LPAR post wakeup from platform idle state
>
> 2. Compensation for the time taken to send the IPI from the source CPU
> (waker) to the idle target CPU (wakee).
>
> 1. can be measured via timer idle test (I am using Pratik's
> cpuidle self-test posted here
> https://lore.kernel.org/lkml/20210412074309.38484-1-psampat@linux.ibm.com/)
>
> We queue a timer, say for 1ms, and enter the CEDE state. When the
> timer fires, in the timer handler we compute how much extra timer over
> the expected 1ms have we consumed. This is what it looks like on
> POWER9 LPAR
>
> CEDE latency measured using a timer (numbers in ns)
> ===================================================================
> N Min Median Avg 90%ile 99%ile Max Stddev
> 400 2601 5677 5668.74 5917 6413 9299 455.01
>
> If we consider the avg and the 99th %ile values, it takes on an avg
> about somewhere between 3.5-4.5 us to transition from the Hypervisor
> to the guest VCPU after the CPU has woken up from the idle state.
>
> 1. and 2. combined can be determined by an IPI latency test (from the
> same self-test linked above). We send an IPI to an idle CPU and in the
> handler compute the time difference between when the IPI was sent and
> when the handler ran. We see the following numbers on POWER9 LPAR.
>
> CEDE latency measured using an IPI (numbers in us)
> ==================================================
> N Min Median Avg 90%ile 99%ile Max Stddev
> 400 711 7564 7369.43 8559 9514 9698 1200.01
>
> Thus considering the avg and the 99th percentile this compensation
> would be 5.4-7.5us.
>
> Suppose, we consider the compensation corresponding to the 99th
> percentile latency value measured using the IPI, the compensation will
> be 7.5us, which will take the total CEDE latency to 9.5us.
>
> This is in the ballpark of the default value of 10us which we obtain
> if we do
>
> if (!p10)
> use default hardcoded value;
>
That's a nice detailed explanation. Maybe you could summarize it in the
commit message so that people looking at the patch in the future can
tell where the value comes from.
Thanks
Michal
^ permalink raw reply
* Re: PPC476 hangs during tlb flush after calling /init in crash kernel with linux 5.4+
From: Christophe Leroy @ 2021-04-28 6:08 UTC (permalink / raw)
To: Eddie James, linuxppc-dev; +Cc: miltonm, linux-kernel, npiggin, paulus
In-Reply-To: <2f7587b1986d597a63169567124438325cbedfd7.camel@linux.ibm.com>
Le 28/04/2021 à 00:42, Eddie James a écrit :
> On Tue, 2021-04-27 at 19:26 +0200, Christophe Leroy wrote:
>> Hi Eddies,
>>
>> Le 27/04/2021 à 19:03, Eddie James a écrit :
>>> Hi all,
>>>
>>> I'm having a problem in simulation and hardware where my PPC476
>>> processor stops executing instructions after callling /init. In my
>>> case
>>> this is a bash script. The code descends to flush the TLB, and
>>> somewhere in the loop in _tlbil_pid, the PC goes to
>>> InstructionTLBError47x but does not go any further. This only
>>> occurs in
>>> the crash kernel environment, which is using the same kernel,
>>> initramfs, and init script as the main kernel, which executed fine.
>>> I
>>> do not see this problem with linux 4.19 or 3.10. I do see it with
>>> 5.4
>>> and 5.10. I see a fair amount of refactoring in the PPC memory
>>> management area between 4.19 and 5.4. Can anyone point me in a
>>> direction to debug this further? My stack trace is below as I can
>>> run
>>> gdb in simulation.
>>
>> Can you bisect to pin point the culprit commit ?
>
> Hi, thanks for your prompt reply.
>
> Good idea! I have bisected to:
>
> commit 9e849f231c3c72d4c3c1b07c9cd19ae789da0420 (b8-bad,
> refs/bisect/bad)
> Author: Christophe Leroy <christophe.leroy@c-s.fr>
> Date: Thu Feb 21 19:08:40 2019 +0000
>
> powerpc/mm/32s: use generic mmu_mapin_ram() for all blocks.
>
> Now that mmu_mapin_ram() is able to handle other blocks
> than the one starting at 0, the WII can use it for all
> its blocks.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> I also confirmed that reverting this commit resolves the issue in 5.4+.
>
> Now, I don't understand why this is problematic or what is really
> happening... Reverting is probably not the desired solution.
>
Can you provide the 'dmesg' or a dump of the logs printed by the kernel at boottime ?
The difference with this commit is that if there are several memblocks, all get mapped. Maybe your
target doesn't like it.
You are talking about simulation, are you using QEMU ? If yes can you provide details so that I can
try and reproduce the issue ?
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
From: Gautham R Shenoy @ 2021-04-28 5:58 UTC (permalink / raw)
To: Michal Suchánek
Cc: Gautham R. Shenoy, linux-pm, Aneesh Kumar K.V, Daniel Lezcano,
Rafael J. Wysocki, joedecke, linuxppc-dev
In-Reply-To: <20210425110714.GH6564@kitsune.suse.cz>
Hello Michal,
On Sun, Apr 25, 2021 at 01:07:14PM +0200, Michal Suchánek wrote:
> On Sat, Apr 24, 2021 at 01:07:16PM +0530, Vaidyanathan Srinivasan wrote:
> > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 20:42:16]:
> >
> > > On Fri, Apr 23, 2021 at 11:59:30PM +0530, Vaidyanathan Srinivasan wrote:
> > > > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 19:45:05]:
> > > >
> > > > > On Fri, Apr 23, 2021 at 09:29:39PM +0530, Vaidyanathan Srinivasan wrote:
> > > > > > * Michal Such?nek <msuchanek@suse.de> [2021-04-23 09:35:51]:
> > > > > >
> > > > > > > On Thu, Apr 22, 2021 at 08:37:29PM +0530, Gautham R. Shenoy wrote:
> > > > > > > > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> > > > > > > >
> > > > > > > > Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> > > > > > > > CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> > > > > > > > of the Extended CEDE states advertised by the platform
> > > > > > > >
> > > > > > > > On some of the POWER9 LPARs, the older firmwares advertise a very low
> > > > > > > > value of 2us for CEDE1 exit latency on a Dedicated LPAR. However the
> > > > > > > Can you be more specific about 'older firmwares'?
> > > > > >
> > > > > > Hi Michal,
> > > > > >
> > > > > > This is POWER9 vs POWER10 difference, not really an obsolete FW. The
> > > > > > key idea behind the original patch was to make the H_CEDE latency and
> > > > > > hence target residency come from firmware instead of being decided by
> > > > > > the kernel. The advantage is such that, different type of systems in
> > > > > > POWER10 generation can adjust this value and have an optimal H_CEDE
> > > > > > entry criteria which balances good single thread performance and
> > > > > > wakeup latency. Further we can have additional H_CEDE state to feed
> > > > > > into the cpuidle.
> > > > >
> > > > > So all POWER9 machines are affected by the firmware bug where firmware
> > > > > reports CEDE1 exit latency of 2us and the real latency is 5us which
> > > > > causes the kernel to prefer CEDE1 too much when relying on the values
> > > > > supplied by the firmware. It is not about 'older firmware'.
> > > >
> > > > Correct. All POWER9 systems running Linux as guest LPARs will see
> > > > extra usage of CEDE idle state, but not baremetal (PowerNV).
> > > >
> > > > The correct definition of the bug or miss-match in expectation is that
> > > > firmware reports wakeup latency from a core/thread wakeup timing, but
> > > > not end-to-end time from sending a wakeup event like an IPI using
> > > > H_calls and receiving the events on the target. Practically there are
> > > > few extra micro-seconds needed after deciding to wakeup a target
> > > > core/thread to getting the target to start executing instructions
> > > > within the LPAR instance.
> > >
> > > Thanks for the detailed explanation.
> > >
> > > Maybe just adding a few microseconds to the reported time would be a
> > > more reasonable workaround than using a blanket fixed value then.
> >
> > Yes, that is an option. But that may only reduce the difference
> > between existing kernel and new kernel unless we make it the same
> > number. Further we are fixing this in P10 and hence we will have to
> > add "if(P9) do the compensation" and otherwise take it as is. That
> > would not be elegant. Given that our goal for P9 platform is to not
> > introduce changes in H_CEDE entry behaviour, we arrived at this
> > approach (this small patch) and this also makes it easy to backport to
> > various distro products.
>
> I don't see how this is more elegent.
>
> The current patch is
>
> if(p9)
> use fixed value
>
> the suggested patch is
>
> if(p9)
> apply compensation
We could do that, however, from the recent measurements the default
value is closer to the latency value measured using an IPI.
As Vaidy described earlier, on POWER9 and prior platforms, the wakeup
latency advertized by the PHYP hypervisor corresponds to the latency
required to wakeup from the underlying hardware idle state (Nap in
POWER8 and stop0/1/2 on POWER9) into the hypervisor. That's 2us on
POWER9.
We need to apply two kinds of compensation,
1. Compensation for the time taken to transition the CPU from the
Hypervisor into the LPAR post wakeup from platform idle state
2. Compensation for the time taken to send the IPI from the source CPU
(waker) to the idle target CPU (wakee).
1. can be measured via timer idle test (I am using Pratik's
cpuidle self-test posted here
https://lore.kernel.org/lkml/20210412074309.38484-1-psampat@linux.ibm.com/)
We queue a timer, say for 1ms, and enter the CEDE state. When the
timer fires, in the timer handler we compute how much extra timer over
the expected 1ms have we consumed. This is what it looks like on
POWER9 LPAR
CEDE latency measured using a timer (numbers in ns)
===================================================================
N Min Median Avg 90%ile 99%ile Max Stddev
400 2601 5677 5668.74 5917 6413 9299 455.01
If we consider the avg and the 99th %ile values, it takes on an avg
about somewhere between 3.5-4.5 us to transition from the Hypervisor
to the guest VCPU after the CPU has woken up from the idle state.
1. and 2. combined can be determined by an IPI latency test (from the
same self-test linked above). We send an IPI to an idle CPU and in the
handler compute the time difference between when the IPI was sent and
when the handler ran. We see the following numbers on POWER9 LPAR.
CEDE latency measured using an IPI (numbers in us)
==================================================
N Min Median Avg 90%ile 99%ile Max Stddev
400 711 7564 7369.43 8559 9514 9698 1200.01
Thus considering the avg and the 99th percentile this compensation
would be 5.4-7.5us.
Suppose, we consider the compensation corresponding to the 99th
percentile latency value measured using the IPI, the compensation will
be 7.5us, which will take the total CEDE latency to 9.5us.
This is in the ballpark of the default value of 10us which we obtain
if we do
if (!p10)
use default hardcoded value;
>
> That is either will add one branch for the affected platform.
>
Since POWER10 onwards, the latency value advertized by the hypervisor
will be the latency as observed by the LPAR VCPU, any new code that we
will be adding will only be applicable for POWER9. We can get the same
effect by using the default value.
Given this, if you feel that it might still be worth pursuing the
compensation approach, I will send out a patch for that.
> But I understand if you do not have confidence that the compensation is
> the same in all cases and do not have the opportunity to measure it it
> may be simpler to apply one very conservative adjustment.
>
> Thanks
>
> Michal
--
Thanks and Regards
gautham.
^ permalink raw reply
* [RFC PATCH] usb: gadget: fsl_qe_udc: fix implicit-fallthrough warnings
From: Randy Dunlap @ 2021-04-28 4:08 UTC (permalink / raw)
To: linux-usb; +Cc: Randy Dunlap, linuxppc-dev, Li Yang
Quieten implicit-fallthrough warnings in fsl_qe_udc.c:
../drivers/usb/gadget/udc/fsl_qe_udc.c: In function 'qe_ep_init':
../drivers/usb/gadget/udc/fsl_qe_udc.c:542:37: warning: this statement may fall through [-Wimplicit-fallthrough=]
542 | if ((max == 128) || (max == 256) || (max == 512))
../drivers/usb/gadget/udc/fsl_qe_udc.c:563:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
563 | if (max <= 1024)
../drivers/usb/gadget/udc/fsl_qe_udc.c:566:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
566 | if (max <= 64)
../drivers/usb/gadget/udc/fsl_qe_udc.c:580:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
580 | if (max <= 1024)
../drivers/usb/gadget/udc/fsl_qe_udc.c:596:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
596 | switch (max) {
This basically just documents what is currently being done.
If any of them need to do something else, just say so or
even make the change.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Li Yang <leoyang.li@nxp.com>
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/usb/gadget/udc/fsl_qe_udc.c | 5 +++++
1 file changed, 5 insertions(+)
--- linux-next-20210427.orig/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ linux-next-20210427/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -541,6 +541,7 @@ static int qe_ep_init(struct qe_udc *udc
case USB_SPEED_HIGH:
if ((max == 128) || (max == 256) || (max == 512))
break;
+ fallthrough;
default:
switch (max) {
case 4:
@@ -562,9 +563,11 @@ static int qe_ep_init(struct qe_udc *udc
case USB_SPEED_HIGH:
if (max <= 1024)
break;
+ fallthrough;
case USB_SPEED_FULL:
if (max <= 64)
break;
+ fallthrough;
default:
if (max <= 8)
break;
@@ -579,6 +582,7 @@ static int qe_ep_init(struct qe_udc *udc
case USB_SPEED_HIGH:
if (max <= 1024)
break;
+ fallthrough;
case USB_SPEED_FULL:
if (max <= 1023)
break;
@@ -605,6 +609,7 @@ static int qe_ep_init(struct qe_udc *udc
default:
goto en_done;
}
+ fallthrough;
case USB_SPEED_LOW:
switch (max) {
case 1:
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS adb68c38d8d49a3d60805479c558649bb2182473
From: kernel test robot @ 2021-04-28 3:45 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: adb68c38d8d49a3d60805479c558649bb2182473 powerpc/papr_scm: Mark nvdimm as unarmed if needed during probe
elapsed time: 812m
configs tested: 174
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
sh sh03_defconfig
powerpc mpc837x_mds_defconfig
microblaze defconfig
parisc allyesconfig
arm axm55xx_defconfig
arm keystone_defconfig
arc alldefconfig
arm colibri_pxa270_defconfig
sh magicpanelr2_defconfig
m68k m5407c3_defconfig
mips mtx1_defconfig
powerpc mvme5100_defconfig
powerpc ppc40x_defconfig
mips nlm_xlr_defconfig
mips maltaup_defconfig
mips rs90_defconfig
powerpc mpc83xx_defconfig
openrisc simple_smp_defconfig
mips bcm47xx_defconfig
h8300 alldefconfig
powerpc linkstation_defconfig
arm pxa255-idp_defconfig
powerpc kmeter1_defconfig
arm alldefconfig
arm shannon_defconfig
mips mpc30x_defconfig
sh shmin_defconfig
sh migor_defconfig
arc axs103_defconfig
sh kfr2r09-romimage_defconfig
arm spear6xx_defconfig
powerpc g5_defconfig
m68k sun3x_defconfig
m68k m5272c3_defconfig
arm socfpga_defconfig
openrisc or1klitex_defconfig
parisc generic-64bit_defconfig
arm nhk8815_defconfig
arm colibri_pxa300_defconfig
xtensa xip_kc705_defconfig
sh apsh4a3a_defconfig
arm stm32_defconfig
s390 alldefconfig
mips maltaaprp_defconfig
sh edosk7760_defconfig
arm mvebu_v5_defconfig
ia64 gensparse_defconfig
xtensa nommu_kc705_defconfig
powerpc amigaone_defconfig
sh sh7724_generic_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
sh titan_defconfig
sh se7619_defconfig
arm integrator_defconfig
mips ar7_defconfig
mips capcella_defconfig
arc defconfig
arc allyesconfig
s390 zfcpdump_defconfig
mips cu1000-neo_defconfig
sh r7785rp_defconfig
mips omega2p_defconfig
sh lboxre2_defconfig
m68k m5307c3_defconfig
powerpc arches_defconfig
mips allmodconfig
powerpc bluestone_defconfig
arm mainstone_defconfig
arm milbeaut_m10v_defconfig
powerpc tqm8548_defconfig
powerpc wii_defconfig
arm spear13xx_defconfig
powerpc ppa8548_defconfig
powerpc mpc836x_mds_defconfig
mips malta_kvm_defconfig
sh espt_defconfig
powerpc bamboo_defconfig
arm cm_x300_defconfig
sh urquell_defconfig
riscv nommu_k210_sdcard_defconfig
m68k sun3_defconfig
sh alldefconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
sh sdk7780_defconfig
h8300 edosk2674_defconfig
xtensa virt_defconfig
sh rsk7203_defconfig
microblaze mmu_defconfig
riscv alldefconfig
m68k amcore_defconfig
sh sh7785lcr_32bit_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210426
i386 randconfig-a002-20210426
i386 randconfig-a001-20210426
i386 randconfig-a006-20210426
i386 randconfig-a004-20210426
i386 randconfig-a003-20210426
x86_64 randconfig-a002-20210427
x86_64 randconfig-a004-20210427
x86_64 randconfig-a001-20210427
x86_64 randconfig-a006-20210427
x86_64 randconfig-a005-20210427
x86_64 randconfig-a003-20210427
x86_64 randconfig-a015-20210426
x86_64 randconfig-a016-20210426
x86_64 randconfig-a011-20210426
x86_64 randconfig-a014-20210426
x86_64 randconfig-a012-20210426
x86_64 randconfig-a013-20210426
i386 randconfig-a014-20210426
i386 randconfig-a012-20210426
i386 randconfig-a011-20210426
i386 randconfig-a013-20210426
i386 randconfig-a015-20210426
i386 randconfig-a016-20210426
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210426
x86_64 randconfig-a004-20210426
x86_64 randconfig-a001-20210426
x86_64 randconfig-a006-20210426
x86_64 randconfig-a005-20210426
x86_64 randconfig-a003-20210426
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS ee1bc694fbaec1a662770703fc34a74abf418938
From: kernel test robot @ 2021-04-28 3:45 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: ee1bc694fbaec1a662770703fc34a74abf418938 powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n
elapsed time: 813m
configs tested: 175
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
sh sh03_defconfig
powerpc mpc837x_mds_defconfig
microblaze defconfig
parisc allyesconfig
arm axm55xx_defconfig
arm keystone_defconfig
arc alldefconfig
arm colibri_pxa270_defconfig
sh magicpanelr2_defconfig
arm pxa255-idp_defconfig
sh ecovec24_defconfig
powerpc mpc836x_mds_defconfig
m68k m5407c3_defconfig
mips mtx1_defconfig
powerpc mvme5100_defconfig
powerpc ppc40x_defconfig
mips nlm_xlr_defconfig
mips maltaup_defconfig
mips rs90_defconfig
powerpc mpc83xx_defconfig
openrisc simple_smp_defconfig
mips bcm47xx_defconfig
h8300 alldefconfig
powerpc linkstation_defconfig
powerpc kmeter1_defconfig
arm alldefconfig
arm shannon_defconfig
mips mpc30x_defconfig
sh shmin_defconfig
sh migor_defconfig
arc axs103_defconfig
sh kfr2r09-romimage_defconfig
arm spear6xx_defconfig
powerpc g5_defconfig
m68k sun3x_defconfig
m68k m5272c3_defconfig
arm socfpga_defconfig
openrisc or1klitex_defconfig
ia64 defconfig
parisc generic-64bit_defconfig
arm nhk8815_defconfig
arm colibri_pxa300_defconfig
xtensa xip_kc705_defconfig
sh apsh4a3a_defconfig
arm stm32_defconfig
s390 alldefconfig
mips maltaaprp_defconfig
sh edosk7760_defconfig
arm mvebu_v5_defconfig
ia64 gensparse_defconfig
xtensa nommu_kc705_defconfig
powerpc amigaone_defconfig
sh sh7724_generic_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
sh titan_defconfig
sh se7619_defconfig
arm integrator_defconfig
arc defconfig
arc allyesconfig
mips ar7_defconfig
mips capcella_defconfig
s390 zfcpdump_defconfig
mips cu1000-neo_defconfig
sh r7785rp_defconfig
mips omega2p_defconfig
sh lboxre2_defconfig
m68k m5307c3_defconfig
powerpc arches_defconfig
mips allmodconfig
powerpc bluestone_defconfig
arm mainstone_defconfig
arm milbeaut_m10v_defconfig
powerpc tqm8548_defconfig
powerpc wii_defconfig
arm spear13xx_defconfig
powerpc ppa8548_defconfig
mips malta_kvm_defconfig
sh espt_defconfig
powerpc bamboo_defconfig
arm cm_x300_defconfig
sh urquell_defconfig
riscv nommu_k210_sdcard_defconfig
m68k sun3_defconfig
sh alldefconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
sh sdk7780_defconfig
h8300 edosk2674_defconfig
xtensa virt_defconfig
sh rsk7203_defconfig
microblaze mmu_defconfig
riscv alldefconfig
m68k amcore_defconfig
sh sh7785lcr_32bit_defconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210426
i386 randconfig-a002-20210426
i386 randconfig-a001-20210426
i386 randconfig-a006-20210426
i386 randconfig-a004-20210426
i386 randconfig-a003-20210426
x86_64 randconfig-a002-20210427
x86_64 randconfig-a004-20210427
x86_64 randconfig-a001-20210427
x86_64 randconfig-a006-20210427
x86_64 randconfig-a005-20210427
x86_64 randconfig-a003-20210427
x86_64 randconfig-a015-20210426
x86_64 randconfig-a016-20210426
x86_64 randconfig-a011-20210426
x86_64 randconfig-a014-20210426
x86_64 randconfig-a012-20210426
x86_64 randconfig-a013-20210426
i386 randconfig-a014-20210426
i386 randconfig-a012-20210426
i386 randconfig-a011-20210426
i386 randconfig-a013-20210426
i386 randconfig-a015-20210426
i386 randconfig-a016-20210426
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210426
x86_64 randconfig-a004-20210426
x86_64 randconfig-a001-20210426
x86_64 randconfig-a006-20210426
x86_64 randconfig-a005-20210426
x86_64 randconfig-a003-20210426
---
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 1b628dbc3ccb0b51963fcb3c60b57daac21dc016
From: kernel test robot @ 2021-04-28 3:45 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: 1b628dbc3ccb0b51963fcb3c60b57daac21dc016 Automatic merge of 'master' into merge (2021-04-27 23:47)
elapsed time: 814m
configs tested: 131
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
x86_64 allyesconfig
riscv allmodconfig
i386 allyesconfig
riscv allyesconfig
mips maltaup_defconfig
mips rs90_defconfig
powerpc mpc83xx_defconfig
microblaze defconfig
openrisc simple_smp_defconfig
mips bcm47xx_defconfig
h8300 alldefconfig
sh kfr2r09-romimage_defconfig
arm spear6xx_defconfig
powerpc g5_defconfig
m68k sun3x_defconfig
m68k m5272c3_defconfig
arm colibri_pxa300_defconfig
xtensa xip_kc705_defconfig
sh apsh4a3a_defconfig
arm stm32_defconfig
s390 alldefconfig
mips maltaaprp_defconfig
powerpc amigaone_defconfig
sh sh7724_generic_defconfig
ia64 tiger_defconfig
mips jmr3927_defconfig
arm xcep_defconfig
powerpc mpc885_ads_defconfig
powerpc chrp32_defconfig
powerpc powernv_defconfig
sh microdev_defconfig
arm mmp2_defconfig
mips ip22_defconfig
arm moxart_defconfig
arm pcm027_defconfig
arm tegra_defconfig
xtensa common_defconfig
sh se7721_defconfig
powerpc bluestone_defconfig
arm mainstone_defconfig
arm milbeaut_m10v_defconfig
powerpc tqm8548_defconfig
sh alldefconfig
m68k m5475evb_defconfig
mips fuloong2e_defconfig
sh sdk7780_defconfig
arm keystone_defconfig
h8300 edosk2674_defconfig
xtensa virt_defconfig
sh rsk7203_defconfig
microblaze mmu_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210426
i386 randconfig-a002-20210426
i386 randconfig-a001-20210426
i386 randconfig-a006-20210426
i386 randconfig-a004-20210426
i386 randconfig-a003-20210426
i386 randconfig-a005-20210427
i386 randconfig-a002-20210427
i386 randconfig-a001-20210427
i386 randconfig-a006-20210427
i386 randconfig-a004-20210427
i386 randconfig-a003-20210427
x86_64 randconfig-a015-20210426
x86_64 randconfig-a016-20210426
x86_64 randconfig-a011-20210426
x86_64 randconfig-a014-20210426
x86_64 randconfig-a012-20210426
x86_64 randconfig-a013-20210426
i386 randconfig-a014-20210426
i386 randconfig-a012-20210426
i386 randconfig-a011-20210426
i386 randconfig-a013-20210426
i386 randconfig-a015-20210426
i386 randconfig-a016-20210426
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um allmodconfig
um allnoconfig
um allyesconfig
um defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210426
x86_64 randconfig-a004-20210426
x86_64 randconfig-a001-20210426
x86_64 randconfig-a006-20210426
x86_64 randconfig-a005-20210426
x86_64 randconfig-a003-20210426
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: PPC32: Boot regression on Nintendo Wii, after create_branch rework in 5.8
From: Jordan Niethe @ 2021-04-28 1:33 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: Emmanuel Gil Peyrot, linuxppc-dev, Alistair Popple
In-Reply-To: <YIWNZI4YhFuRZwHg@latitude>
On Mon, Apr 26, 2021 at 1:40 AM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> Hi,
>
> I recently booted my Wii again, and I noticed a regression at boot time.
> Output stops after the "Finalizing device tree... flat tree at 0xXXXXXX"
> message. I bisected it to this commit in the 5.8 development cycle:
>
> commit 7c95d8893fb55869882c9f68f4c94840dc43f18f
> Author: Jordan Niethe <jniethe5@gmail.com>
> Date: Wed May 6 13:40:25 2020 +1000
>
> powerpc: Change calling convention for create_branch() et. al.
>
> create_branch(), create_cond_branch() and translate_branch() return the
> instruction that they create, or return 0 to signal an error. Separate
> these concerns in preparation for an instruction type that is not just
> an unsigned int. Fill the created instruction to a pointer passed as
> the first parameter to the function and use a non-zero return value to
> signify an error.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Alistair Popple <alistair@popple.id.au>
> Link: https://lore.kernel.org/r/20200506034050.24806-6-jniethe5@gmail.com
>
> arch/powerpc/include/asm/code-patching.h | 12 +--
> arch/powerpc/kernel/optprobes.c | 24 +++---
> arch/powerpc/kernel/setup_32.c | 4 +-
> arch/powerpc/kernel/trace/ftrace.c | 24 +++---
> arch/powerpc/lib/code-patching.c | 134 ++++++++++++++++++-------------
> arch/powerpc/lib/feature-fixups.c | 5 +-
> 6 files changed, 119 insertions(+), 84 deletions(-)
>
>
> Do you have any hints on how to debug and/or fix this issue?
Thanks for bisecting and reporting.
The "Finalizing device tree... flat tree at 0xXXXXXX" message comes
from the bootwrapper so if that is the last output it must be crashing
pretty early.
Commit 7c95d8893fb5 ("powerpc: Change calling convention for
create_branch() et. al.") made a change to machine_init() in
setup_32.c which seems like it might be a likely culprit for causing
early crashing.
The branch that is created and patched is just for optimization, so to
see if that is in fact the problem it might be worth trying to boot
with a patch like below
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -87,9 +87,6 @@ notrace void __init machine_init(u64 dt_ptr)
patch_instruction_site(&patch__memcpy_nocache, ppc_inst(PPC_INST_NOP));
- create_cond_branch(&insn, addr, branch_target(addr), 0x820000);
- patch_instruction(addr, insn); /* replace b by bne cr0 */
-
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
>
>
> Best regards,
> Jonathan Neuschäfer
^ permalink raw reply
* Re: powerpc{32,64} randconfigs
From: Randy Dunlap @ 2021-04-28 1:31 UTC (permalink / raw)
To: Christophe Leroy, PowerPC; +Cc: linux-kbuild
In-Reply-To: <c973768b-8fe5-a5a4-ccfc-ebc109b6eb80@infradead.org>
On 4/20/21 11:45 PM, Randy Dunlap wrote:
> On 4/20/21 11:37 PM, Christophe Leroy wrote:
>>
>>
>> Le 21/04/2021 à 01:31, Randy Dunlap a écrit :
>>> --- linux-next-20210420.orig/arch/powerpc/kernel/vdso64/Makefile
>>> +++ linux-next-20210420/arch/powerpc/kernel/vdso64/Makefile
>>> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-bu
>>> asflags-y := -D__VDSO64__ -s
>>> targets += vdso64.lds
>>> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
>>> +CPPFLAGS_vdso64.lds += -P -C -U$(SRCARCH)
>>
>> Maybe it would be better to do -Upowerpc like in VDSO32
>>
>
> OK, thanks for getting that done. :)
>
>>> # link rule for the .so file, .lds has to be first
>>> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
>>> --- linux-next-20210420.orig/arch/powerpc/Makefile
Just to wrap this up, I got this method working also.
Thanks for all of your help, Christophe.
--
~Randy
^ permalink raw reply
* Re: [PATCH v6] powerpc/kexec_file: use current CPU info while setting up FDT
From: Tyrel Datwyler @ 2021-04-28 0:32 UTC (permalink / raw)
To: Sourabh Jain, mpe; +Cc: mahesh, bauerman, hbathini, stable, linuxppc-dev
In-Reply-To: <20210427045120.2109980-1-sourabhjain@linux.ibm.com>
On 4/26/21 9:51 PM, Sourabh Jain wrote:
> kexec_file_load uses initial_boot_params in setting up the device-tree
> for the kernel to be loaded. Though initial_boot_params holds info
> about CPUs at the time of boot, it doesn't account for hot added CPUs.
>
> So, kexec'ing with kexec_file_load syscall would leave the kexec'ed
> kernel with inaccurate CPU info. Also, if kdump kernel is loaded with
> kexec_file_load syscall and the system crashes on a hot added CPU,
> capture kernel hangs failing to identify the boot CPU.
>
> Kernel panic - not syncing: sysrq triggered crash
> CPU: 24 PID: 6065 Comm: echo Kdump: loaded Not tainted 5.12.0-rc5upstream #54
> Call Trace:
> [c0000000e590fac0] [c0000000007b2400] dump_stack+0xc4/0x114 (unreliable)
> [c0000000e590fb00] [c000000000145290] panic+0x16c/0x41c
> [c0000000e590fba0] [c0000000008892e0] sysrq_handle_crash+0x30/0x40
> [c0000000e590fc00] [c000000000889cdc] __handle_sysrq+0xcc/0x1f0
> [c0000000e590fca0] [c00000000088a538] write_sysrq_trigger+0xd8/0x178
> [c0000000e590fce0] [c0000000005e9b7c] proc_reg_write+0x10c/0x1b0
> [c0000000e590fd10] [c0000000004f26d0] vfs_write+0xf0/0x330
> [c0000000e590fd60] [c0000000004f2aec] ksys_write+0x7c/0x140
> [c0000000e590fdb0] [c000000000031ee0] system_call_exception+0x150/0x290
> [c0000000e590fe10] [c00000000000ca5c] system_call_common+0xec/0x278
> --- interrupt: c00 at 0x7fff905b9664
> NIP: 00007fff905b9664 LR: 00007fff905320c4 CTR: 0000000000000000
> REGS: c0000000e590fe80 TRAP: 0c00 Not tainted (5.12.0-rc5upstream)
> MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28000242
> XER: 00000000
> IRQMASK: 0
> GPR00: 0000000000000004 00007ffff5fedf30 00007fff906a7300 0000000000000001
> GPR04: 000001002a7355b0 0000000000000002 0000000000000001 00007ffff5fef616
> GPR08: 0000000000000001 0000000000000000 0000000000000000 0000000000000000
> GPR12: 0000000000000000 00007fff9073a160 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 00007fff906a4ee0 0000000000000002 0000000000000001
> GPR24: 00007fff906a0898 0000000000000000 0000000000000002 000001002a7355b0
> GPR28: 0000000000000002 00007fff906a1790 000001002a7355b0 0000000000000002
> NIP [00007fff905b9664] 0x7fff905b9664
> LR [00007fff905320c4] 0x7fff905320c4
> --- interrupt: c00
>
> To avoid this from happening, extract current CPU info from of_root
> device node and use it for setting up the fdt in kexec_file_load case.
>
> Fixes: 6ecd0163d360 ("powerpc/kexec_file: Add appropriate regions for memory reserve map")
>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Reviewed-by: Hari Bathini <hbathini@linux.ibm.com>
> Cc: <stable@vger.kernel.org>
> ---
> arch/powerpc/kexec/file_load_64.c | 88 +++++++++++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
>
> ---
> Changelog:
>
> v1 -> v5
> - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-April/227950.html
>
> v5 -> v6
> - use exiting macro (for_each_property_of_node) to loop through all
> properties of a node.
> - removed devtree_lock while accessing the node properties.
> - function name update, add_node_prop to add_node_props.
> ---
>
> diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
> index 02b9e4d0dc40..4f7d4c10f939 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -960,6 +960,89 @@ unsigned int kexec_fdt_totalsize_ppc64(struct kimage *image)
> return fdt_size;
> }
>
> +/**
> + * add_node_props - Reads node properties from device node structure and add
> + * them to fdt.
> + * @fdt: Flattened device tree of the kernel
> + * @node_offset: offset of the node to add a property at
> + * @dn: device node pointer
> + *
> + * Returns 0 on success, negative errno on error.
> + */
> +static int add_node_props(void *fdt, int node_offset, const struct device_node *dn)
> +{
> + int ret = 0;
> + struct property *pp;
> +
> + if (!dn)
> + return -EINVAL;
> +
> + for_each_property_of_node(dn, pp) {
> + ret = fdt_setprop(fdt, node_offset, pp->name, pp->value, pp->length);
> + if (ret < 0) {
> + pr_err("Unable to add %s property: %s\n", pp->name, fdt_strerror(ret));
> + return ret;
> + }
> + }
> + return ret;
> +}
> +
> +/**
> + * update_cpus_node - Update cpus node of flattened device tree using of_root
> + * device node.
> + * @fdt: Flattened device tree of the kernel.
> + *
> + * Returns 0 on success, negative errno on error.
> + */
> +static int update_cpus_node(void *fdt)
> +{
> + struct device_node *cpus_node, *dn;
> + int cpus_offset, cpus_subnode_offset, ret = 0;
> +
> + cpus_offset = fdt_path_offset(fdt, "/cpus");
> + if (cpus_offset < 0 && cpus_offset != -FDT_ERR_NOTFOUND) {
> + pr_err("Malformed device tree: error reading /cpus node: %s\n",
> + fdt_strerror(cpus_offset));
> + return cpus_offset;
> + }
> +
> + if (cpus_offset > 0) {
> + ret = fdt_del_node(fdt, cpus_offset);
> + if (ret < 0) {
> + pr_err("Error deleting /cpus node: %s\n", fdt_strerror(ret));
> + return -EINVAL;
> + }
> + }
> +
> + /* Add cpus node to fdt */
> + cpus_offset = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"), "cpus");
> + if (cpus_offset < 0) {
> + pr_err("Error creating /cpus node: %s\n", fdt_strerror(cpus_offset));
> + return -EINVAL;
> + }
> +
> + /* Add cpus node properties */
> + cpus_node = of_find_node_by_path("/cpus");
Pretty sure that of_find_node_by_path() returns a device_node with its refcount
incremented.
> + ret = add_node_props(fdt, cpus_offset, cpus_node);
Need a of_node_put(cpus_node) here.
-Tyrel
> + if (ret < 0)
> + return ret;
> +
> + /* Loop through all subnodes of cpus and add them to fdt */
> + for_each_node_by_type(dn, "cpu") {
> + cpus_subnode_offset = fdt_add_subnode(fdt, cpus_offset, dn->full_name);
> + if (cpus_subnode_offset < 0) {
> + pr_err("Unable to add %s subnode: %s\n", dn->full_name,
> + fdt_strerror(cpus_subnode_offset));
> + return cpus_subnode_offset;
> + }
> + ret = add_node_props(fdt, cpus_subnode_offset, dn);
> + if (ret < 0)
> + return ret;
> + }
> + of_node_put(dn);
> + return ret;
> +}
> +
> /**
> * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
> * being loaded.
> @@ -1020,6 +1103,11 @@ int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
> }
> }
>
> + /* Update cpus nodes information to account hotplug CPUs. */
> + ret = update_cpus_node(fdt);
> + if (ret < 0)
> + return ret;
> +
> /* Update memory reserve map */
> ret = get_reserved_memory_ranges(&rmem);
> if (ret)
>
^ permalink raw reply
* Re: powerpc{32,64} randconfigs
From: Randy Dunlap @ 2021-04-27 23:45 UTC (permalink / raw)
To: Michael Ellerman, PowerPC; +Cc: linux-kbuild
In-Reply-To: <87tuo0az16.fsf@mpe.ellerman.id.au>
On 4/21/21 12:15 AM, Michael Ellerman wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>> Hi,
>>
>> Is there a way to do this?
>>
>> $ make ARCH=powerpc randconfig # and force PPC32
>
> Sort of:
>
> $ KCONFIG_ALLCONFIG=arch/powerpc/configs/book3s_32.config make randconfig
>
> But that also forces BOOK3S.
>
>> and separately
>> $ make ARCH=powerpc randconfig # and force PPC64
>
> No.
>
> ...
>> OK, I have a patch that seems for work as far as setting
>> PPC32=y or PPC64=y... but it has a problem during linking
>> of vmlinux:
>>
>> crosstool/gcc-9.3.0-nolibc/powerpc-linux/bin/powerpc-linux-ld:./arch/powerpc/kernel/vmlinux.lds:6: syntax error
>>
>> and the (bad) generated vmlinux.lds file says (at line 6):
>>
>> OUTPUT_ARCH(1:common)
>>
>> while it should say:
>>
>> OUTPUT_ARCH(powerpc:common)
>>
>> Does anyone have any ideas about this problem?
>
> I guess your patch broke something? :D
> Not sure sorry.
>
> What about something like this?
>
> cheers
>
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 3212d076ac6a..712c5e8768ce 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -376,6 +376,16 @@ PHONY += ppc64_book3e_allmodconfig
> $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \
> -f $(srctree)/Makefile allmodconfig
>
> +PHONY += ppc32_randconfig
> +ppc32_randconfig:
> + $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \
> + -f $(srctree)/Makefile randconfig
> +
> +PHONY += ppc64_randconfig
> +ppc64_randconfig:
> + $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \
> + -f $(srctree)/Makefile randconfig
> +
> define archhelp
> @echo '* zImage - Build default images selected by kernel config'
> @echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
> diff --git a/arch/powerpc/configs/32-bit.config b/arch/powerpc/configs/32-bit.config
> new file mode 100644
> index 000000000000..bdf833009006
> --- /dev/null
> +++ b/arch/powerpc/configs/32-bit.config
> @@ -0,0 +1 @@
> +CONFIG_PPC64=n
I used the suggested change here (above).
> diff --git a/arch/powerpc/configs/64-bit.config b/arch/powerpc/configs/64-bit.config
> new file mode 100644
> index 000000000000..0fe6406929e2
> --- /dev/null
> +++ b/arch/powerpc/configs/64-bit.config
> @@ -0,0 +1 @@
> +CONFIG_PPC64=y
>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Please merge this. :)
thanks.
--
~Randy
^ permalink raw reply
* Re: PPC476 hangs during tlb flush after calling /init in crash kernel with linux 5.4+
From: Eddie James @ 2021-04-27 22:42 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev; +Cc: miltonm, linux-kernel, npiggin, paulus
In-Reply-To: <a24e9e0d-1d4f-506b-9303-4b995815d3c4@csgroup.eu>
On Tue, 2021-04-27 at 19:26 +0200, Christophe Leroy wrote:
> Hi Eddies,
>
> Le 27/04/2021 à 19:03, Eddie James a écrit :
> > Hi all,
> >
> > I'm having a problem in simulation and hardware where my PPC476
> > processor stops executing instructions after callling /init. In my
> > case
> > this is a bash script. The code descends to flush the TLB, and
> > somewhere in the loop in _tlbil_pid, the PC goes to
> > InstructionTLBError47x but does not go any further. This only
> > occurs in
> > the crash kernel environment, which is using the same kernel,
> > initramfs, and init script as the main kernel, which executed fine.
> > I
> > do not see this problem with linux 4.19 or 3.10. I do see it with
> > 5.4
> > and 5.10. I see a fair amount of refactoring in the PPC memory
> > management area between 4.19 and 5.4. Can anyone point me in a
> > direction to debug this further? My stack trace is below as I can
> > run
> > gdb in simulation.
>
> Can you bisect to pin point the culprit commit ?
Hi, thanks for your prompt reply.
Good idea! I have bisected to:
commit 9e849f231c3c72d4c3c1b07c9cd19ae789da0420 (b8-bad,
refs/bisect/bad)
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Thu Feb 21 19:08:40 2019 +0000
powerpc/mm/32s: use generic mmu_mapin_ram() for all blocks.
Now that mmu_mapin_ram() is able to handle other blocks
than the one starting at 0, the WII can use it for all
its blocks.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
I also confirmed that reverting this commit resolves the issue in 5.4+.
Now, I don't understand why this is problematic or what is really
happening... Reverting is probably not the desired solution.
Thanks
Eddie
>
> Assuming the problem is in arch/powerpc/ , you should get the result
> in approx 10 steps:
>
> [root@po15610vm linux-powerpc]# git bisect start -- arch/powerpc/
> [root@po15610vm linux-powerpc]# git bisect bad v5.4
> [root@po15610vm linux-powerpc]# git bisect good v4.19
> Bisecting: 964 revisions left to test after this (roughly 10 steps)
>
>
> Christophe
^ permalink raw reply
* PPC476 hangs during tlb flush after calling /init in crash kernel with linux 5.4+
From: Eddie James @ 2021-04-27 17:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: miltonm, linux-kernel, npiggin, paulus
Hi all,
I'm having a problem in simulation and hardware where my PPC476
processor stops executing instructions after callling /init. In my case
this is a bash script. The code descends to flush the TLB, and
somewhere in the loop in _tlbil_pid, the PC goes to
InstructionTLBError47x but does not go any further. This only occurs in
the crash kernel environment, which is using the same kernel,
initramfs, and init script as the main kernel, which executed fine. I
do not see this problem with linux 4.19 or 3.10. I do see it with 5.4
and 5.10. I see a fair amount of refactoring in the PPC memory
management area between 4.19 and 5.4. Can anyone point me in a
direction to debug this further? My stack trace is below as I can run
gdb in simulation.
Thanks,
Eddie
#0 _tlbil_pid () at
/usr/src/kernel/arch/powerpc/mm/nohash/tlb_low.S:123
#1 0xca014864 in local_flush_tlb_mm (mm=<optimized out>)
at /usr/src/kernel/arch/powerpc/mm/nohash/tlb.c:201
#2 tlb_flush (tlb=<optimized out>)
at /usr/src/kernel/arch/powerpc/mm/nohash/tlb.c:395
#3 0xca161e48 in tlb_flush_mmu_tlbonly (tlb=<optimized out>)
at /usr/src/kernel/include/asm-generic/tlb.h:408
#4 tlb_flush_mmu_tlbonly (tlb=<optimized out>)
at /usr/src/kernel/include/asm-generic/tlb.h:403
#5 tlb_flush_mmu (tlb=0xcec2fd18) at
/usr/src/kernel/mm/mmu_gather.c:190
#6 0xca161fa8 in tlb_finish_mmu (tlb=0xcec2fd18, start=<optimized
out>,
end=<optimized out>) at /usr/src/kernel/mm/mmu_gather.c:272
#7 0xca18e070 in shift_arg_pages (shift=<optimized out>,
vma=<optimized out>)
at /usr/src/kernel/fs/exec.c:678
#8 setup_arg_pages (bprm=0xcef1a000, stack_top=<optimized out>,
executable_stack=<optimized out>) at /usr/src/kernel/fs/exec.c:768
#9 0xca1f617c in load_elf_binary (bprm=0xcef1a000)
at /usr/src/kernel/fs/binfmt_elf.c:867
#10 0xca18f3d4 in search_binary_handler (bprm=<optimized out>)
at /usr/src/kernel/fs/exec.c:1691
#11 0xca1f458c in next_terminator (last=<optimized out>,
first=<optimized out>)
at /usr/src/kernel/fs/binfmt_script.c:29
#12 load_script (bprm=0xcef1a000) at
/usr/src/kernel/fs/binfmt_script.c:83
#13 0xca18f3d4 in search_binary_handler (bprm=<optimized out>)
at /usr/src/kernel/fs/exec.c:1691
#14 0xca190104 in acct_arg_size (bprm=<optimized out>, pages=<optimized
out>)
at /usr/src/kernel/fs/exec.c:187
#15 __do_execve_file (fd=<optimized out>, filename=0xcec98000,
argv=...,
envp=..., flags=<optimized out>, file=<optimized out>)
at /usr/src/kernel/fs/exec.c:1872
#16 0xca19059c in __read_once_size (size=<optimized out>,
res=<optimized out>, p=<optimized out>) at
/usr/src/kernel/include/linux/compiler.h:235
#17 set_dumpable (mm=<optimized out>, value=<optimized out>) at
/usr/src/kernel/fs/exec.c:1983
^ permalink raw reply
* Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Nick Desaulniers @ 2021-04-27 20:42 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Nathan Chancellor, linuxppc-dev, clang-built-linux
In-Reply-To: <de6fc09f-97f5-c934-6393-998ec766b48a@csgroup.eu>
On Mon, Apr 26, 2021 at 11:39 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 26/04/2021 à 20:50, Nathan Chancellor a écrit :
> > On Sat, Mar 20, 2021 at 11:22:27PM +1100, Michael Ellerman wrote:
> >> From: Christophe Leroy <christophe.leroy@csgroup.eu>
> >>
> >> call_do_irq() and call_do_softirq() are simple enough to be
> >> worth inlining.
> >>
> >> Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. It
> >> also allows GCC to keep the saved ksp_limit in an nonvolatile reg.
> >>
> >> This is inspired from S390 arch. Several other arches do more or
> >> less the same. The way sparc arch does seems odd thought.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> >>
> >
> > This change caused our ppc44x_defconfig builds to hang when powering
> > down in QEMU:
> >
> > https://github.com/ClangBuiltLinux/continuous-integration2/runs/2304364629?check_suite_focus=true#logs
> >
> > This is probably something with clang given that GCC 10.3.0 works fine
> > but due to the nature of the change, I have no idea how to tell what is
> > going wrong. I tried to do some rudimentary debugging with gdb but that
> > did not really get me anywhere.
> >
> > The kernel was built with just 'CC=clang' and it is reproducible with
> > all versions of clang that the kernel supports.
> >
> > The QEMU invocation is visible at the link above, it is done with our
> > boot-qemu.sh in this repo, which also houses the rootfs:
> >
> > https://github.com/ClangBuiltLinux/boot-utils
> >
> > Happy to provide any other information or debug/test as directed!
> >
>
> With GCC:
>
> 000003f0 <do_softirq_own_stack>:
> 3f0: 94 21 ff f0 stwu r1,-16(r1)
> 3f4: 7c 08 02 a6 mflr r0
> 3f8: 3d 20 00 00 lis r9,0
> 3fa: R_PPC_ADDR16_HA .data..read_mostly+0x4
> 3fc: 93 e1 00 0c stw r31,12(r1)
> 400: 90 01 00 14 stw r0,20(r1)
> 404: 83 e9 00 00 lwz r31,0(r9)
> 406: R_PPC_ADDR16_LO .data..read_mostly+0x4
> 408: 94 3f 1f f0 stwu r1,8176(r31)
> 40c: 7f e1 fb 78 mr r1,r31
> 410: 48 00 00 01 bl 410 <do_softirq_own_stack+0x20>
> 410: R_PPC_REL24 __do_softirq
> 414: 80 21 00 00 lwz r1,0(r1)
> 418: 80 01 00 14 lwz r0,20(r1)
> 41c: 83 e1 00 0c lwz r31,12(r1)
> 420: 38 21 00 10 addi r1,r1,16
> 424: 7c 08 03 a6 mtlr r0
> 428: 4e 80 00 20 blr
>
>
> With CLANG:
>
> 000003e8 <do_softirq_own_stack>:
> 3e8: 94 21 ff f0 stwu r1,-16(r1)
> 3ec: 93 c1 00 08 stw r30,8(r1)
> 3f0: 3c 60 00 00 lis r3,0
> 3f2: R_PPC_ADDR16_HA softirq_ctx
> 3f4: 83 c3 00 00 lwz r30,0(r3)
> 3f6: R_PPC_ADDR16_LO softirq_ctx
> 3f8: 94 3e 1f f0 stwu r1,8176(r30)
> 3fc: 7f c1 f3 78 mr r1,r30
> 400: 48 00 00 01 bl 400 <do_softirq_own_stack+0x18>
> 400: R_PPC_REL24 __do_softirq
> 404: 80 21 00 00 lwz r1,0(r1)
> 408: 83 c1 00 08 lwz r30,8(r1)
> 40c: 38 21 00 10 addi r1,r1,16
> 410: 4e 80 00 20 blr
>
>
> As you can see, CLANG doesn't save/restore 'lr' allthought 'lr' is explicitely listed in the
> registers clobbered by the inline assembly:
Ah, thanks for debugging this. Will follow up in
https://bugs.llvm.org/show_bug.cgi?id=50147.
>
> >> +static __always_inline void call_do_softirq(const void *sp)
> >> +{
> >> + /* Temporarily switch r1 to sp, call __do_softirq() then restore r1. */
> >> + asm volatile (
> >> + PPC_STLU " %%r1, %[offset](%[sp]) ;"
> >> + "mr %%r1, %[sp] ;"
> >> + "bl %[callee] ;"
> >> + PPC_LL " %%r1, 0(%%r1) ;"
> >> + : // Outputs
> >> + : // Inputs
> >> + [sp] "b" (sp), [offset] "i" (THREAD_SIZE - STACK_FRAME_OVERHEAD),
> >> + [callee] "i" (__do_softirq)
> >> + : // Clobbers
> >> + "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6",
> >> + "cr7", "r0", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10",
> >> + "r11", "r12"
> >> + );
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/de6fc09f-97f5-c934-6393-998ec766b48a%40csgroup.eu.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] pseries/drmem: update LMBs after LPM
From: Tyrel Datwyler @ 2021-04-27 19:37 UTC (permalink / raw)
To: Laurent Dufour, mpe, benh, paulus; +Cc: nathanl, linuxppc-dev, linux-kernel
In-Reply-To: <20210427181308.17640-1-ldufour@linux.ibm.com>
On 4/27/21 11:13 AM, Laurent Dufour wrote:
> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
> updated by the hypervisor in the case the NUMA topology of the LPAR's
> memory is updated.
>
> This is caught by the kernel, but the memory's node is updated because
> there is no way to move a memory block between nodes.
>
> If later a memory block is added or removed, drmem_update_dt() is called
> and it is overwriting the DT node to match the added or removed LMB. But
> the LMB's associativity node has not been updated after the DT node update
> and thus the node is overwritten by the Linux's topology instead of the
> hypervisor one.
>
> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
> updated to force an update of the LMB's associativity.
>
> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>
> Change since V1:
> - Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
> introducing a new hook mechanism.
> ---
> arch/powerpc/include/asm/drmem.h | 1 +
> arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
> .../platforms/pseries/hotplug-memory.c | 4 +++
> 3 files changed, 40 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
> index bf2402fed3e0..4265d5e95c2c 100644
> --- a/arch/powerpc/include/asm/drmem.h
> +++ b/arch/powerpc/include/asm/drmem.h
> @@ -111,6 +111,7 @@ int drmem_update_dt(void);
> int __init
> walk_drmem_lmbs_early(unsigned long node, void *data,
> int (*func)(struct drmem_lmb *, const __be32 **, void *));
> +void drmem_update_lmbs(struct property *prop);
> #endif
>
> static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
> index 9af3832c9d8d..f0a6633132af 100644
> --- a/arch/powerpc/mm/drmem.c
> +++ b/arch/powerpc/mm/drmem.c
> @@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
> return ret;
> }
>
> +/*
> + * Update the LMB associativity index.
> + */
> +static int update_lmb(struct drmem_lmb *updated_lmb,
> + __maybe_unused const __be32 **usm,
> + __maybe_unused void *data)
> +{
> + struct drmem_lmb *lmb;
> +
> + /*
> + * Brut force there may be better way to fetch the LMB
> + */
> + for_each_drmem_lmb(lmb) {
> + if (lmb->drc_index != updated_lmb->drc_index)
> + continue;
> +
> + lmb->aa_index = updated_lmb->aa_index;
> + break;
> + }
> + return 0;
> +}
> +
> +/*
> + * Update the LMB associativity index.
> + *
> + * This needs to be called when the hypervisor is updating the
> + * dynamic-reconfiguration-memory node property.
> + */
> +void drmem_update_lmbs(struct property *prop)
> +{
> + if (!strcmp(prop->name, "ibm,dynamic-memory"))
> + __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
> + else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
> + __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
> +}
> #endif
>
> static int init_drmem_lmb_size(struct device_node *dn)
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 8377f1f7c78e..8aabaafc484b 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
> case OF_RECONFIG_DETACH_NODE:
> err = pseries_remove_mem_node(rd->dn);
> break;
> + case OF_RECONFIG_UPDATE_PROPERTY:
> + if (!strcmp(rd->dn->full_name,
Pretty much a self nit on myself since I just copied the device node name field
from your initial patch into my suggested code block.
It used to be that dn->full_name was intended to store the full device-tree path
name of the device node ane dn->name simply the base name. These days the values
of both name fields are simply the basename for pseries. Regardless,
rd->dn->name is technically correct and shorter.
-Tyrel
> + "ibm,dynamic-reconfiguration-memory"))
> + drmem_update_lmbs(rd->prop);
> }
> return notifier_from_errno(err);
> }
>
^ permalink raw reply
* Re: [PATCH] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-27 18:17 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
In-Reply-To: <20210427181308.17640-1-ldufour@linux.ibm.com>
Michael, this is a v2 despite the mail's subject, sorry for the mess.
^ permalink raw reply
* [PATCH] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-27 18:13 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is caught by the kernel, but the memory's node is updated because
there is no way to move a memory block between nodes.
If later a memory block is added or removed, drmem_update_dt() is called
and it is overwriting the DT node to match the added or removed LMB. But
the LMB's associativity node has not been updated after the DT node update
and thus the node is overwritten by the Linux's topology instead of the
hypervisor one.
Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
updated to force an update of the LMB's associativity.
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Change since V1:
- Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
introducing a new hook mechanism.
---
arch/powerpc/include/asm/drmem.h | 1 +
arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
.../platforms/pseries/hotplug-memory.c | 4 +++
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index bf2402fed3e0..4265d5e95c2c 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -111,6 +111,7 @@ int drmem_update_dt(void);
int __init
walk_drmem_lmbs_early(unsigned long node, void *data,
int (*func)(struct drmem_lmb *, const __be32 **, void *));
+void drmem_update_lmbs(struct property *prop);
#endif
static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 9af3832c9d8d..f0a6633132af 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
return ret;
}
+/*
+ * Update the LMB associativity index.
+ */
+static int update_lmb(struct drmem_lmb *updated_lmb,
+ __maybe_unused const __be32 **usm,
+ __maybe_unused void *data)
+{
+ struct drmem_lmb *lmb;
+
+ /*
+ * Brut force there may be better way to fetch the LMB
+ */
+ for_each_drmem_lmb(lmb) {
+ if (lmb->drc_index != updated_lmb->drc_index)
+ continue;
+
+ lmb->aa_index = updated_lmb->aa_index;
+ break;
+ }
+ return 0;
+}
+
+/*
+ * Update the LMB associativity index.
+ *
+ * This needs to be called when the hypervisor is updating the
+ * dynamic-reconfiguration-memory node property.
+ */
+void drmem_update_lmbs(struct property *prop)
+{
+ if (!strcmp(prop->name, "ibm,dynamic-memory"))
+ __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
+ else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
+ __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
+}
#endif
static int init_drmem_lmb_size(struct device_node *dn)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8377f1f7c78e..8aabaafc484b 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
case OF_RECONFIG_DETACH_NODE:
err = pseries_remove_mem_node(rd->dn);
break;
+ case OF_RECONFIG_UPDATE_PROPERTY:
+ if (!strcmp(rd->dn->full_name,
+ "ibm,dynamic-reconfiguration-memory"))
+ drmem_update_lmbs(rd->prop);
}
return notifier_from_errno(err);
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-27 17:28 UTC (permalink / raw)
To: Tyrel Datwyler, mpe, benh, paulus; +Cc: nathanl, linuxppc-dev, linux-kernel
In-Reply-To: <8b36065d-e4b4-bc0c-cf69-f01c91e49061@linux.ibm.com>
Le 27/04/2021 à 19:01, Tyrel Datwyler a écrit :
> On 4/27/21 8:01 AM, Laurent Dufour wrote:
>> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
>> updated by the hypervisor in the case the NUMA topology of the LPAR's
>> memory is updated.
>>
>> This is caught by the kernel, but the memory's node is updated because
>> there is no way to move a memory block between nodes.
>>
>> If later a memory block is added or removed, drmem_update_dt() is called
>> and it is overwriting the DT node to match the added or removed LMB. But
>> the LMB's associativity node has not been updated after the DT node update
>> and thus the node is overwritten by the Linux's topology instead of the
>> hypervisor one.
>>
>> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
>> updated to force an update of the LMB's associativity.
>>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>> arch/powerpc/include/asm/drmem.h | 1 +
>> arch/powerpc/mm/drmem.c | 48 +++++++++++++++++++++++
>> arch/powerpc/platforms/pseries/mobility.c | 9 +++++
>> 3 files changed, 58 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
>> index bf2402fed3e0..55c2c25085b0 100644
>> --- a/arch/powerpc/include/asm/drmem.h
>> +++ b/arch/powerpc/include/asm/drmem.h
>> @@ -111,6 +111,7 @@ int drmem_update_dt(void);
>> int __init
>> walk_drmem_lmbs_early(unsigned long node, void *data,
>> int (*func)(struct drmem_lmb *, const __be32 **, void *));
>> +void drmem_update_lmbs(void);
>> #endif
>>
>> static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>> index 9af3832c9d8d..46074bdfdb3c 100644
>> --- a/arch/powerpc/mm/drmem.c
>> +++ b/arch/powerpc/mm/drmem.c
>> @@ -307,6 +307,54 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
>> return ret;
>> }
>>
>> +/*
>> + * Update the LMB associativity index.
>> + */
>> +static int update_lmb(struct drmem_lmb *updated_lmb,
>> + __maybe_unused const __be32 **usm,
>> + __maybe_unused void *data)
>> +{
>> + struct drmem_lmb *lmb;
>> +
>> + /*
>> + * Brut force there may be better way to fetch the LMB
>> + */
>> + for_each_drmem_lmb(lmb) {
>> + if (lmb->drc_index != updated_lmb->drc_index)
>> + continue;
>> +
>> + lmb->aa_index = updated_lmb->aa_index;
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> +/*
>> + * Update the LMB associativity index.
>> + *
>> + * This needs to be called when the hypervisor is updating the
>> + * dynamic-reconfiguration-memory node property.
>> + */
>> +void drmem_update_lmbs(void)
>> +{
>> + struct device_node *node;
>> + const __be32 *prop;
>> +
>> + node = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> + if (!node)
>> + return;
>> +
>> + prop = of_get_property(node, "ibm,dynamic-memory", NULL);
>> + if (prop) {
>> + __walk_drmem_v1_lmbs(prop, NULL, NULL, update_lmb);
>> + } else {
>> + prop = of_get_property(node, "ibm,dynamic-memory-v2", NULL);
>> + if (prop)
>> + __walk_drmem_v2_lmbs(prop, NULL, NULL, update_lmb);
>> + }
>> +
>> + of_node_put(node);
>> +}
>> #endif
>>
>> static int init_drmem_lmb_size(struct device_node *dn)
>> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
>> index ea4d6a660e0d..c68eccc6e8df 100644
>> --- a/arch/powerpc/platforms/pseries/mobility.c
>> +++ b/arch/powerpc/platforms/pseries/mobility.c
>> @@ -25,6 +25,7 @@
>>
>> #include <asm/machdep.h>
>> #include <asm/rtas.h>
>> +#include <asm/drmem.h>
>> #include "pseries.h"
>> #include "../../kernel/cacheinfo.h"
>>
>> @@ -237,6 +238,7 @@ int pseries_devicetree_update(s32 scope)
>> __be32 *data;
>> int update_nodes_token;
>> int rc;
>> + bool drmem_updated = false;
>>
>> update_nodes_token = rtas_token("ibm,update-nodes");
>> if (update_nodes_token == RTAS_UNKNOWN_SERVICE)
>> @@ -271,6 +273,10 @@ int pseries_devicetree_update(s32 scope)
>> continue;
>> }
>>
>> + if (!strcmp(np->full_name,
>> + "ibm,dynamic-reconfiguration-memory"))
>> + drmem_updated = true;
>
> Is there a reason that we can't use the existing pseries_memory_notifier()
> callback in pseries/hotplug-memory.c to trigger the drmem_update_lmbs() when
> either the ibm,dynamic-memory or ibm,dynamic-memory-v2 properties are updated?
Thanks a lot Tyrel!
That's far more elegant, I'll send a v2 soon.
Laurent.
> Something like:
>
> static int pseries_memory_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> struct of_reconfig_data *rd = data;
> int err = 0;
>
> switch (action) {
> case OF_RECONFIG_ATTACH_NODE:
> err = pseries_add_mem_node(rd->dn);
> break;
> case OF_RECONFIG_DETACH_NODE:
> err = pseries_remove_mem_node(rd->dn);
> break;
> case OF_RECONFIG_UPDATE_PROPERTY:
> if (!strcmp(rd->dn->full_name, "ibm,dynamic-reconfiguration-memory"));
> drmem_update_lmbs(rd->prop);
> break;
> }
> return notifier_from_errno(err);
> }
>
> Your drmem_update_lmbs() would need to be updated to take a property and to
> check the property name against ibm,dyanmic-memory[-v2].
>
> -Tyrel
>
>> +
>> switch (action) {
>> case DELETE_DT_NODE:
>> delete_dt_node(np);
>> @@ -293,6 +299,9 @@ int pseries_devicetree_update(s32 scope)
>> } while (rc == 1);
>>
>> kfree(rtas_buf);
>> +
>> + if (drmem_updated)
>> + drmem_update_lmbs();
>> return rc;
>> }
>>
>
^ 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