Re: microwatt booting linux-5.7 under verilator
Le 03/01/2022 à 01:45, Luke Kenneth Casson Leighton a écrit : > i am pleased to be able to announce the successful booting of microwatt-5.7 > linux buildroot... under a veriilator simulation of the microwatt VHDL. > from a hardware development and research perspective this is highly > significant because unlike the FPGA boot which was previously reported, > https://shenki.github.io/boot-linux-on-microwatt/ > full memory read/write snooping and full Signal tracing (gtkwave) is possible. > > https://ftp.libre-soc.org/microwatt-linux-5.7-verilator-boot-buildroot.txt > > the branch of microwatt HDL which is being used is here > https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace > > some minor strategic changes to microwatt HDL were required, including > adding a new SYSCON parameter to specify a BRAM chain-boot address, > and also it was necessary to turn sdram_init into a stand-alone "mini-BIOS" > which performed the role of early-initialising the 16550 uart followed by > chain-loading to the BRAM chain-boot memory location, at which the linux > 5.7 dtbImage.microwatt had been loaded (0x60). > > microwatt-verilator.cpp itself needed some changes to add support for > emulation in c++ of 512 mbyte of "Block" RAM. the interface for BRAM > (aka SRAM) was far simpler than attempting to emulate DRAM, and > also meant that much of the mini-BIOS could be entirely cut. > > i also had to further modify microwatt-verilator.cpp to allow it to load > from files directly into memory, at run-time. this means it is possible > to execute hello_world.bin, zephyr.bin, micropython.bin, dtbImage-microwatt > all without recompiling the verilator binary. > > (not that you want to try compiling a 6 MB binary into VHDL like i did: > it resulted in the creation of a 512 MB verilog file which, at 60 GB resident > RAM by verilator attempting to compile that to c++, i decided that mayyybe > doing that at runtime was a better approach?) > > i also had to fix a couple of things in the linux kernel source > https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git > > first attempts to boot a compressed image were quite hilarious: a > quick back-of-the-envelope calculation by examining the rate at which > LD/STs were being generated showed that the GZIP decompression > would complete maybe some time in about 1 hour of real-world time. > this led me to add support for CONFIG_KERNEL_UNCOMPRESSED > and cut that time entirely, hence why you can see this in the console log: > > 0x5b0e10 bytes of uncompressed data copied > > secondly, the microwatt Makefile assumes that verilator clock rate > runs at 50 mhz, where the microwatt.dts file says 100 mhz for both > the UART clock as well as the system clock. it would be really nice > to have microwatt-linux read the SYSCON parameter for the > clock rate, and for that to be dynamically inserted into the dtb. > however in the interim, the attached patch suffices by manually > altering the clock in microwatt.dts to match that of the SYSCON > parameter. I'm not sure whether you expect this attached patch to me merged in mainline. If so, could you re-submit as a proper patch ? Thanks Christophe
Re: [PATCH v7 3/5] powerpc: Rework and improve STRICT_KERNEL_RWX patching
Hi Jordan
Le 10/11/2021 à 01:37, Jordan Niethe a écrit :
> From: "Christopher M. Riedl"
>
> Rework code-patching with STRICT_KERNEL_RWX to prepare for a later patch
> which uses a temporary mm for patching under the Book3s64 Radix MMU.
> Make improvements by adding a WARN_ON when the patchsite doesn't match
> after patching and return the error from __patch_instruction() properly.
>
> Signed-off-by: Christopher M. Riedl
> Signed-off-by: Jordan Niethe
> ---
> v7: still pass addr to map_patch_area()
This patch doesn-t apply, can you rebase the series ?
Thanks
Christophe
> ---
> arch/powerpc/lib/code-patching.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/lib/code-patching.c
> b/arch/powerpc/lib/code-patching.c
> index 29a30c3068ff..d586bf9c7581 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -75,6 +75,7 @@ static inline void stop_using_temp_mm(struct temp_mm_state
> prev_state)
> }
>
> static DEFINE_PER_CPU(struct vm_struct *, text_poke_area);
> +static DEFINE_PER_CPU(unsigned long, cpu_patching_addr);
>
> static int text_area_cpu_up(unsigned int cpu)
> {
> @@ -87,6 +88,7 @@ static int text_area_cpu_up(unsigned int cpu)
> return -1;
> }
> this_cpu_write(text_poke_area, area);
> + this_cpu_write(cpu_patching_addr, (unsigned long)area->addr);
>
> return 0;
> }
> @@ -172,11 +174,10 @@ static inline int unmap_patch_area(unsigned long addr)
>
> static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
> {
> - int err;
> + int err, rc = 0;
> u32 *patch_addr = NULL;
> unsigned long flags;
> unsigned long text_poke_addr;
> - unsigned long kaddr = (unsigned long)addr;
>
> /*
>* During early early boot patch_instruction is called
> @@ -188,15 +189,13 @@ static int do_patch_instruction(u32 *addr, struct
> ppc_inst instr)
>
> local_irq_save(flags);
>
> - text_poke_addr = (unsigned long)__this_cpu_read(text_poke_area)->addr;
> - if (map_patch_area(addr, text_poke_addr)) {
> - err = -1;
> + text_poke_addr = __this_cpu_read(cpu_patching_addr);
> + err = map_patch_area(addr, text_poke_addr);
> + if (err)
> goto out;
> - }
> -
> - patch_addr = (u32 *)(text_poke_addr + (kaddr & ~PAGE_MASK));
>
> - __patch_instruction(addr, instr, patch_addr);
> + patch_addr = (u32 *)(text_poke_addr | offset_in_page(addr));
> + rc = __patch_instruction(addr, instr, patch_addr);
>
> err = unmap_patch_area(text_poke_addr);
> if (err)
> @@ -204,8 +203,9 @@ static int do_patch_instruction(u32 *addr, struct
> ppc_inst instr)
>
> out:
> local_irq_restore(flags);
> + WARN_ON(!ppc_inst_equal(ppc_inst_read(addr), instr));
>
> - return err;
> + return rc ? rc : err;
> }
> #else /* !CONFIG_STRICT_KERNEL_RWX */
>
Re: [PATCH V7 13/20] riscv: compat: process: Add UXL_32 support in start_thread
On Fri, Mar 11, 2022 at 9:38 PM Ben Dooks wrote:
>
> On 11/03/2022 02:38, Guo Ren wrote:
> > Hi Arnd,
> >
> > On Mon, Feb 28, 2022 at 12:30 AM wrote:
> >>
> >> From: Guo Ren
> >>
> >> If the current task is in COMPAT mode, set SR_UXL_32 in status for
> >> returning userspace. We need CONFIG _COMPAT to prevent compiling
> >> errors with rv32 defconfig.
> >>
> >> Signed-off-by: Guo Ren
> >> Signed-off-by: Guo Ren
> >> Cc: Arnd Bergmann
> >> Cc: Palmer Dabbelt
> >> ---
> >> arch/riscv/kernel/process.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> >> index 03ac3aa611f5..54787ca9806a 100644
> >> --- a/arch/riscv/kernel/process.c
> >> +++ b/arch/riscv/kernel/process.c
> >> @@ -97,6 +97,11 @@ void start_thread(struct pt_regs *regs, unsigned long
> >> pc,
> >> }
> >> regs->epc = pc;
> >> regs->sp = sp;
> >> +
> > FIxup:
> >
> > + #ifdef CONFIG_COMPAT
> >> + if (is_compat_task())
> >> + regs->status = (regs->status & ~SR_UXL) | SR_UXL_32;
> >> + else
> >> + regs->status = (regs->status & ~SR_UXL) | SR_UXL_64;
> > + #endif
> >
> > We still need "#ifdef CONFIG_COMPAT" here, because for rv32 we can't
> > set SR_UXL at all. SR_UXL is BIT[32, 33].
>
> would an if (IS_ENABLED(CONFIG_COMPAT)) { } around the lot be better
> than an #ifdef here?
I don't think, seems #ifdef CONFIG_COMPAT is more commonly used in arch/*
>
> >> }
> >>
> >> void flush_thread(void)
> >> --
> >> 2.25.1
> >>
> >
> >
>
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
>
> https://www.codethink.co.uk/privacy.html
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.17-6 tag
The pull request you sent on Fri, 11 Mar 2022 17:03:15 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.17-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/878409ecde7c89c9f3db76ff1ef9486c6ceed02c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[powerpc:topic/ppc-kvm] BUILD SUCCESS f771b55731fc82b1e8e9ef123f6f1b8d8c92bc63
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm branch HEAD: f771b55731fc82b1e8e9ef123f6f1b8d8c92bc63 KVM: PPC: Use KVM_CAP_PPC_AIL_MODE_3 elapsed time: 742m configs tested: 123 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig i386 randconfig-c001 arm cm_x300_defconfig arm eseries_pxa_defconfig sh sh7770_generic_defconfig powerpc tqm8548_defconfig mips maltasmvp_eva_defconfig sh sh03_defconfig powerpc ep8248e_defconfig xtensa iss_defconfig arm omap2plus_defconfig shtitan_defconfig pariscgeneric-64bit_defconfig mipsmaltaup_xpa_defconfig arcvdk_hs38_smp_defconfig openrisc simple_smp_defconfig armmps2_defconfig arm badge4_defconfig sh se7721_defconfig sh se7750_defconfig armshmobile_defconfig arcnsim_700_defconfig powerpcmpc7448_hpc2_defconfig powerpc canyonlands_defconfig shedosk7705_defconfig powerpc ppc64_defconfig ia64 gensparse_defconfig mips db1xxx_defconfig arm pxa3xx_defconfig openrisc alldefconfig powerpc holly_defconfig powerpc mpc837x_mds_defconfig powerpc motionpro_defconfig h8300 edosk2674_defconfig arm stm32_defconfig mips decstation_r4k_defconfig shsh7757lcr_defconfig arm randconfig-c002-20220310 arm randconfig-c002-20220311 ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc64defconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig i386 debian-10.3-kselftests i386 debian-10.3 mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64rhel-8.3-kselftests um x86_64_defconfig um i386_defconfig x86_64 allyesconfig x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-func x86_64 rhel-8.3-kunit x86_64 kexec clang tested configs: arm
Re: [PATCHv5 0/3] enable nr_cpus for powerpc
Le 23/03/2018 à 06:28, Pingfan Liu a écrit : Maintainers, ping? Any comment? This series doesn't apply anymore, and it has build failure report from the robot. If it's still relevant, please rebase and fix. Christophe Thanks On Thu, Mar 15, 2018 at 12:41 PM, Pingfan Liu wrote: This topic has a very long history. It comes from Mahesh Salgaonkar For v3: https://patchwork.ozlabs.org/patch/834860/ I hope we can acquire it for "kexec -p" soon. V4->V5: improve the [1/3] implementation based on Benjamin's suggestion. Mahesh Salgaonkar (1): ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit. Pingfan Liu (2): powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt powerpc, cpu: handling the special case when boot_cpuid greater than nr_cpus arch/powerpc/include/asm/paca.h| 3 +++ arch/powerpc/include/asm/smp.h | 2 ++ arch/powerpc/kernel/paca.c | 19 ++- arch/powerpc/kernel/prom.c | 27 --- arch/powerpc/kernel/setup-common.c | 35 --- 5 files changed, 67 insertions(+), 19 deletions(-) -- 2.7.4
Re: [PATCH 1/4] ASoC: fsl-asoc-card: add WM8904 support
On Mon, Mar 07, 2022 at 11:10:38AM -0300, Alifer Moraes wrote: > From: Pierluigi Passaro > > The codec WM8904 can use internal FLL as PLL source. > Whenever the PLL source is not an external MCLK, this source > must be setup during hw_params callback otherwise the BCLK > could be wrongly evaluated. > The SND_SOC_BIAS_PREPARE event is raised after the hw_params > callback, so there is no need to set again PLL and SYSCLK and > actually there's no need at all the set_bias_level function. > Also, when esai is used, a dedicated snd_soc_dai_set_tdm_slot > Signed-off by: Alifer Moraes > > Signed-off-by: Pierluigi Passaro When you're sending a mail your signoff should come at the end of the chain of signoffs - see submitting-patches.rst for details. This breaks an arm64 defconfig build: /mnt/kernel/sound/soc/fsl/fsl-asoc-card.c: In function 'fsl_asoc_card_hw_free': /mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:265:37: error: 'struct snd_soc_pcm_runtime' has no member named 'cpu_dai' 265 | ret = snd_soc_dai_set_tdm_slot(rtd->cpu_dai, 0, 0, 2, | ^~ /mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: error: 'params' undeclared (first use in this function); did you mean 'parameq'? 266 | params_physical_width(params)); | ^~ | parameq /mnt/kernel/sound/soc/fsl/fsl-asoc-card.c:266:35: note: each undeclared identifier is reported only once for each function it appears in signature.asc Description: PGP signature
Re: [FIX PATCH v1] powerpc/pseries: Fix reference count leak during CPU unplug
Le 09/03/2017 à 05:37, Bharata B Rao a écrit :
The following warning is seen when a CPU is hot unplugged on a PowerKVM
guest:
refcount_t: underflow; use-after-free.
[ cut here ]
WARNING: CPU: 0 PID: 53 at lib/refcount.c:128 refcount_sub_and_test+0xd8/0xf0
Modules linked in:
CPU: 0 PID: 53 Comm: kworker/u510:1 Not tainted 4.11.0-rc1 #3
Workqueue: pseries hotplug workque pseries_hp_work_fn
task: c000fb475000 task.stack: c000fb81c000
NIP: c06f0808 LR: c06f0804 CTR: c07b98c0
REGS: c000fb81f710 TRAP: 0700 Not tainted (4.11.0-rc1)
MSR: 8282b033
CR: 4800 XER: 2000
CFAR: c0c438e0 SOFTE: 1
GPR00: c06f0804 c000fb81f990 c1573b00 0026
GPR04: 016c 667265652e0d0a73 652d61667465722d
GPR08: 0007 0007 0001 0006
GPR12: 2200 cff4 c010c578 c001f11b9f40
GPR16: c001fe0312a8 c001fe031078 c001fe031020 0001
GPR20: c1454808 fef7
GPR24: c001f1677648
GPR28: 1008 c0e4d3d8 c001eaae07d8
NIP [c06f0808] refcount_sub_and_test+0xd8/0xf0
LR [c06f0804] refcount_sub_and_test+0xd4/0xf0
Call Trace:
[c000fb81f990] [c06f0804] refcount_sub_and_test+0xd4/0xf0
(unreliable)
[c000fb81f9f0] [c06d04b4] kobject_put+0x44/0x2a0
[c000fb81fa70] [c09d5284] of_node_put+0x34/0x50
[c000fb81faa0] [c00aceb8] dlpar_cpu_remove_by_index+0x108/0x130
[c000fb81fb30] [c00ae128] dlpar_cpu+0x78/0x550
[c000fb81fbe0] [c00a7b40] handle_dlpar_errorlog+0xc0/0x160
[c000fb81fc50] [c00a7c74] pseries_hp_work_fn+0x94/0xa0
[c000fb81fc80] [c0102cec] process_one_work+0x23c/0x540
[c000fb81fd20] [c010309c] worker_thread+0xac/0x620
[c000fb81fdc0] [c010c6c4] kthread+0x154/0x1a0
[c000fb81fe30] [c000bbe0] ret_from_kernel_thread+0x5c/0x7c
Fix this by ensuring that of_node_put() is called only from the
error path in dlpar_cpu_remove_by_index(). In the normal path,
of_node_put() happens as part of dlpar_detach_node().
Signed-off-by: Bharata B Rao
Cc: Nathan Fontenot
Is this patch still needed ?
Thanks
Christophe
---
Changes in v1:
- Fixed the refcount problem in the userspace driven unplug path
in addition to in-kernel unplug path. (Sachin Sant)
v0: https://patchwork.ozlabs.org/patch/736547/
arch/powerpc/platforms/pseries/hotplug-cpu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 7bc0e91..c5ed510 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -619,7 +619,8 @@ static int dlpar_cpu_remove_by_index(u32 drc_index)
}
rc = dlpar_cpu_remove(dn, drc_index);
- of_node_put(dn);
+ if (rc)
+ of_node_put(dn);
return rc;
}
@@ -856,9 +857,12 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t count)
}
rc = dlpar_cpu_remove(dn, drc_index);
- of_node_put(dn);
-
- return rc ? rc : count;
+ if (rc) {
+ of_node_put(dn);
+ return rc;
+ } else {
+ return count;
+ }
}
#endif /* CONFIG_ARCH_CPU_PROBE_RELEASE */
Re: [RFC PATCH v0 2/2] powerpc, drmem: Rename DRMEM_LMB_RESERVED to DRMEM_LMB_ISOLATED
Le 21/02/2018 à 11:36, Bharata B Rao a écrit :
Memory hotplug code uses a temporary LMB flags bit DRMEM_LMB_RESERVED
to mark the LMB which is currently undergoing hotplug or unplug.
It is easy to confuse DRMEM_LMB_RESERVED to mean the LMB is reserved
for which a separate flag bit already exists DRCONF_MEM_RESERVED. Since
both DRMEM_LMB_RESERVED and DRCONF_MEM_RESERVED operate on the same
LMB flags word, rename the former to DRMEM_LMB_ISOLATED.
Nothing has happened since this RFC was posted, we still have it as
'new' in patchwork and it doesn't apply.
I'll flag it as 'RFC' so we keep it in our RFC history.
Christophe
Signed-off-by: Bharata B Rao
---
arch/powerpc/include/asm/drmem.h| 14 -
arch/powerpc/mm/drmem.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 40 -
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
index ce242b9..b3fa3f7 100644
--- a/arch/powerpc/include/asm/drmem.h
+++ b/arch/powerpc/include/asm/drmem.h
@@ -72,21 +72,21 @@ static inline u32 drmem_lmb_size(void)
return drmem_info->lmb_size;
}
-#define DRMEM_LMB_RESERVED 0x8000
+#define DRMEM_LMB_ISOLATED 0x8000
-static inline void drmem_mark_lmb_reserved(struct drmem_lmb *lmb)
+static inline void drmem_mark_lmb_isolated(struct drmem_lmb *lmb)
{
- lmb->flags |= DRMEM_LMB_RESERVED;
+ lmb->flags |= DRMEM_LMB_ISOLATED;
}
-static inline void drmem_remove_lmb_reservation(struct drmem_lmb *lmb)
+static inline void drmem_remove_lmb_isolation(struct drmem_lmb *lmb)
{
- lmb->flags &= ~DRMEM_LMB_RESERVED;
+ lmb->flags &= ~DRMEM_LMB_ISOLATED;
}
-static inline bool drmem_lmb_reserved(struct drmem_lmb *lmb)
+static inline bool drmem_lmb_isolated(struct drmem_lmb *lmb)
{
- return lmb->flags & DRMEM_LMB_RESERVED;
+ return lmb->flags & DRMEM_LMB_ISOLATED;
}
u64 drmem_lmb_memory_max(void);
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index 3f18036..652bf3a 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -35,7 +35,7 @@ static u32 drmem_lmb_flags(struct drmem_lmb *lmb)
* Return the value of the lmb flags field minus the reserved
* bit used internally for hotplug processing.
*/
- return lmb->flags & ~DRMEM_LMB_RESERVED;
+ return lmb->flags & ~DRMEM_LMB_ISOLATED;
}
static struct property *clone_property(struct property *prop, u32 prop_sz)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index c1578f5..2f5ca29 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -467,7 +467,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
/* Mark this lmb so we can add it later if all of the
* requested LMBs cannot be removed.
*/
- drmem_mark_lmb_reserved(lmb);
+ drmem_mark_lmb_isolated(lmb);
lmbs_removed++;
if (lmbs_removed == lmbs_to_remove)
@@ -478,7 +478,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
pr_err("Memory hot-remove failed, adding LMB's back\n");
for_each_drmem_lmb(lmb) {
- if (!drmem_lmb_reserved(lmb))
+ if (!drmem_lmb_isolated(lmb))
continue;
rc = dlpar_add_lmb(lmb);
@@ -486,20 +486,20 @@ static int dlpar_memory_remove_by_count(u32
lmbs_to_remove)
pr_err("Failed to add LMB back, drc index %x\n",
lmb->drc_index);
- drmem_remove_lmb_reservation(lmb);
+ drmem_remove_lmb_isolation(lmb);
}
rc = -EINVAL;
} else {
for_each_drmem_lmb(lmb) {
- if (!drmem_lmb_reserved(lmb))
+ if (!drmem_lmb_isolated(lmb))
continue;
dlpar_release_drc(lmb->drc_index);
pr_info("Memory at %llx was hot-removed\n",
lmb->base_addr);
- drmem_remove_lmb_reservation(lmb);
+ drmem_remove_lmb_isolation(lmb);
}
rc = 0;
}
@@ -608,7 +608,7 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove,
u32 drc_index)
if (rc)
break;
- drmem_mark_lmb_reserved(lmb);
+ drmem_mark_lmb_isolated(lmb);
}
if (rc) {
@@ -616,7 +616,7 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove,
u32 drc_index)
for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
- if (!drmem_lmb_reserved(lmb))
+ if (!drmem_lmb_isolated(
Re: [PATCH v9 0/8] reduce memory consumption for powerpc firmware-assisted capture kernel
Le 15/11/2017 à 16:16, Hari Bathini a écrit : I posted the initial version [1] of patchset [2] adding support to enforce additional parameters when firmware-assisted dump capture kernel is active. Michal reposted it with few improvements to parameter processing to make it more robust. He further posted patchset [3] with few more improvements. This patch series clubs the work from these two patch-sets while segregating the generic and arch-specific code to ease the review process. [1] http://patchwork.ozlabs.org/patch/758176/ [2] http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=2733 [3] http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=3338 Hello, We still have this series flagged as "new" in powerpc's patchwork. It is still of interest ? Patch 1 applies but patch 2 hardly conflicts in init/main.c So I'll flag it as "change requested", fell free to resubmit if still relevant. Or if you think that's still required but don't plan to handle it, tell me and I'll open an issue in our issue board so that we don't loose history. Thanks Christophe --- Hari Bathini (2): powerpc/fadump: reduce memory consumption for capture kernel powerpc/fadump: update documentation about 'fadump_extra_args=' parameter Michal Suchanek (6): lib/cmdline.c: remove quotes symmetrically boot/param: add pointer to current and next argument to unknown parameter callback lib/cmdline.c: add backslash support to kernel commandline parsing Documentation/admin-guide: backslash support in commandline lib/cmdline.c: implement single quotes in commandline argument parsing Documentation/admin-guide: single quotes in kernel arguments Documentation/admin-guide/kernel-parameters.rst |5 + Documentation/powerpc/firmware-assisted-dump.txt | 20 - arch/powerpc/include/asm/fadump.h|2 arch/powerpc/kernel/fadump.c | 97 +- arch/powerpc/kernel/prom.c |7 ++ include/linux/moduleparam.h |1 init/main.c |8 +- kernel/module.c |5 + kernel/params.c | 18 +++- lib/cmdline.c| 54 +++- lib/dynamic_debug.c |1 11 files changed, 179 insertions(+), 39 deletions(-)
Re: [RFC PATCH] powerpc/uprobes: Fixup si_addr if we took an exception while single stepping
Le 13/09/2017 à 22:03, Naveen N. Rao a écrit :
If the single-stepped instruction causes an exception, we may end up
setting siginfo.si_addr to the address of the uprobe xol area. This is
not desirable since the address won't make sense for the process if it
wants to handle the exception. Fixup the si_addr field in such cases.
Reported-by: Anton Blanchard
Signed-off-by: Naveen N. Rao
Nowadays _exception() calls force_sig_fault_to_task() so if the change
is still required I guess it must be done there ?
Christophe
---
arch/powerpc/include/asm/uprobes.h | 7 +++
arch/powerpc/kernel/traps.c| 4
arch/powerpc/kernel/uprobes.c | 17 +
3 files changed, 28 insertions(+)
diff --git a/arch/powerpc/include/asm/uprobes.h
b/arch/powerpc/include/asm/uprobes.h
index 7422a999a39a..13fc6af3c1fd 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
typedef ppc_opcode_t uprobe_opcode_t;
@@ -45,4 +46,10 @@ struct arch_uprobe_task {
unsigned long saved_trap_nr;
};
+#ifdef CONFIG_UPROBES
+extern void uprobe_fixup_exception(struct pt_regs *regs, siginfo_t *info);
+#else
+static inline void uprobe_fixup_exception(struct pt_regs *regs, siginfo_t
*info) { }
+#endif
+
#endif/* _ASM_UPROBES_H */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index ec74e203ee04..1bb858a37029 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC_CORE)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -292,6 +293,9 @@ void _exception(int signr, struct pt_regs *regs, int code,
unsigned long addr)
info.si_signo = signr;
info.si_code = code;
info.si_addr = (void __user *) addr;
+
+ uprobe_fixup_exception(regs, &info);
+
force_sig_info(signr, &info, current);
}
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index 5d105b8eeece..a361a56e6210 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
@@ -214,3 +215,19 @@ bool arch_uretprobe_is_alive(struct return_instance *ret, enum rp_check ctx,
else
return regs->gpr[1] < ret->stack;
}
+
+void uprobe_fixup_exception(struct pt_regs *regs, siginfo_t *info)
+{
+ struct task_struct *t = current;
+ struct uprobe_task *utask = t->utask;
+
+ if (likely(!utask || !utask->active_uprobe))
+ return;
+
+ /*
+* We reset si_addr here.
+* regs->nip is reset during our way back through uprobe_deny_signal()
+*/
+ if (info->si_addr == (void __user *) utask->xol_vaddr)
+ info->si_addr = (void __user *) utask->vaddr;
+}
Re: [PATCH] powerpc/tm: fix live state of vs0/32 in tm_reclaim
Le 04/07/2017 à 22:45, Gustavo Romero a écrit :
Currently tm_reclaim() can return with a corrupted vs0 (fp0) or vs32 (v0)
due to the fact vs0 is used to save FPSCR and vs32 is used to save VSCR.
Later, we recheckpoint trusting that the live state of FP and VEC are ok
depending on the MSR.FP and MSR.VEC bits, i.e. if MSR.FP is enabled that
means the FP registers checkpointed when we entered in TM are correct and
after a treclaim. we can trust the FP live state. Similarly to VEC regs.
However if tm_reclaim() does not return a sane state then tm_recheckpoint()
will recheckpoint a corrupted state from live state back to the checkpoint
area.
That commit fixes the corruption by restoring vs0 and vs32 from the
ckfp_state and ckvr_state after they are used to save FPSCR and VSCR,
respectively.
The effect of the issue described above is observed, for instance, once a
VSX unavailable exception is caught in the middle of a transaction with
MSR.FP = 1 or MSR.VEC = 1. If MSR.FP = 1, then after getting back to user
space FP state is corrupted. If MSR.VEC = 1, then VEC state is corrupted.
The issue does not occur if MSR.FP = 0 and MSR.VEC = 0 because ckfp_state
and ckvr_state are both copied from fp_state and vr_state, respectively,
and on recheckpointing both states will be restored from these thread
structures and not from the live state.
The issue does not occur also if MSR.FP = 1 and MSR.VEC = 1 because it
implies MSR.VSX = 1 and in that case the VSX unavailable exception does not
happen in the middle of the transactional block.
Finally, that commit also fixes the MSR used to check if FP and VEC bits
are enabled once we are in tm_reclaim_thread(). ckpt_regs.msr is valid only
if giveup_all() is called *before* using ckpt_regs.msr for checks because
check_if_tm_restore_required() in giveup_all() will copy regs->msr to
ckpt_regs.msr and so ckpt_regs.msr reflects exactly the MSR that the thread
had when it came off the processor.
No regression was observed on powerpc/tm selftests after this fix.
Signed-off-by: Gustavo Romero
Signed-off-by: Breno Leitao
This patch is still flaged as "New" in patchwork
(https://patchwork.ozlabs.org/project/linuxppc-dev/patch/1499201115-22967-1-git-send-email-grom...@linux.vnet.ibm.com/)
I don't know why but the discussion that happened on this patch don't
appear in patchwork.
I see two commit touching the same area of code done in the following
monthes the same year:
eb5c3f1c8647 ("powerpc: Always save/restore checkpointed regs during
treclaim/trecheckpoint")
91381b9cb1c3 ("powerpc: Force reload for recheckpoint during tm {fp,
vec, vsx} unavailable exception")
So I'll mark this patch as "changes requested". Please raise hand if I'm
wrong.
Christophe
Re: [PATCH] Setup per-cpu cpu<->node binding early
Le 18/10/2016 à 09:10, Balbir Singh a écrit :
Michael Ellerman debugged an issue w.r.t workqueue changes
(see https://lkml.org/lkml/2016/10/17/352) down to the fact
that we don't setup our per cpu (cpu to node) binding early
enough (in setup_per_cpu_areas like x86 does).
This lead to a problem with workqueue changes where the
cpus seen by for_each_node() in workqueue_init_early() was
different from their binding seen later in
for_each_possible_cpu(cpu) {
node = cpu_to_node(cpu)
...
}
In setup_arch()->initmem_init() we have access to the binding
in numa_cpu_lookup_table()
This patch implements Michael's suggestion of setting up
the per cpu node binding inside of setup_per_cpu_areas()
I did not remove the original setting of these values
from smp_prepare_cpus(). I've also not setup per cpu
mem's via set_cpu_numa_mem() since zonelists are not
yet built by the time we do per cpu setup.
Reported-by: Michael Ellerman
Signed-off-by: Balbir Singh
I see we still have this patch as "New" in patchwork.
Is it similar to commit ba4a648f12f4 ("powerpc/numa: Fix percpu
allocations to be NUMA aware")
Or is it something else ?
Thanks
Christophe
---
arch/powerpc/kernel/setup_64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index c3e1290..842415a 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -625,6 +625,8 @@ void __init setup_per_cpu_areas(void)
for_each_possible_cpu(cpu) {
__per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
paca[cpu].data_offset = __per_cpu_offset[cpu];
+
+ set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
}
}
#endif
Re: [PATCH] kexec/powerpc: fix exporting memory limit
Le 07/03/2014 à 05:38, Nikita Yushchenko a écrit : On Thu, 2014-03-06 at 18:24 +0400, Nikita Yushchenko wrote: When preparing dump-capturing kernel, kexec userspace tool needs to know actual amount of memory used by the running kernel. This may differ from extire available DRAM for a couple of reasons. To address this issue, kdump kernel support code injects several attributes into device tree that are later captured by userspace kexec tool via /proc interface. One such attrubute is 'chosen/linux,memory_limit' that is used to pass memory limit of the running kernel. This was initialized using kernel's 'memory_limit' variable, that is set by early init code based on mem= kernel parameter and other reasons. But there are cases when memory_limit variable does not contain proper information. One such case is when !CONFIG_HIGHMEM kernel runs on system with memory large enough not to fit into lowmem. Why doesn't the !CONFIG_HIGHMEM code update memory_limit to reflect reality. I guess because memory_limit is used for ... well, memory limit, set by mem=. And for the rest memblock is used (and it *is* updated). And code elsewhere does use memblock, see e.g. numa_enforce_memory_limit() in arch/powerpc/mm/numa.c In MMU init (MMU_init() in arch/powerpc/mm/init_32.c -which is the point where final memory configuration is set) memblock, not memory_limit, is both used and updated. We still have this patch as "New" in patchwork. I don't know if it is relevant but directory structure has changed so if still needed this patch needs rebase. Christophe
Re: [PATCH v2] powerpc/32: Add support for out-of-line static calls
Hi Peter, Le 31/08/2021 à 16:00, Peter Zijlstra a écrit : On Tue, Aug 31, 2021 at 01:12:26PM +, Christophe Leroy wrote: Yes, this should work nicely! Since you have the two nop's at the end, you could frob in an optimization for __static_call_return0 without too much issue. Replace the two nops with (excuse my ppc asm): li r3, 0 blr and augment arch_static_call_transform() with something like: if (func == &__static_call_return0) err = patch_branch(tramp, tramp+24, 0); I just discovered that we likely have an issue with the implementation of that RET0 static call. Looking at System.map I have: c0004fc0 t __static_call_return0 c0011518 t __static_call_return0 c00d8160 t __static_call_return0 So when we do: if (func == &__static_call_return0) It is unlikely that we'll get the expected one. I see __static_call_return0 is defined as 'static inline' in include/linux/static_call.h Any reason for not having it as a single global symbol instead ? Thanks Christophe
Re: [PATCH V7 13/20] riscv: compat: process: Add UXL_32 support in start_thread
On 11/03/2022 02:38, Guo Ren wrote:
Hi Arnd,
On Mon, Feb 28, 2022 at 12:30 AM wrote:
From: Guo Ren
If the current task is in COMPAT mode, set SR_UXL_32 in status for
returning userspace. We need CONFIG _COMPAT to prevent compiling
errors with rv32 defconfig.
Signed-off-by: Guo Ren
Signed-off-by: Guo Ren
Cc: Arnd Bergmann
Cc: Palmer Dabbelt
---
arch/riscv/kernel/process.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 03ac3aa611f5..54787ca9806a 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -97,6 +97,11 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
}
regs->epc = pc;
regs->sp = sp;
+
FIxup:
+ #ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ regs->status = (regs->status & ~SR_UXL) | SR_UXL_32;
+ else
+ regs->status = (regs->status & ~SR_UXL) | SR_UXL_64;
+ #endif
We still need "#ifdef CONFIG_COMPAT" here, because for rv32 we can't
set SR_UXL at all. SR_UXL is BIT[32, 33].
would an if (IS_ENABLED(CONFIG_COMPAT)) { } around the lot be better
than an #ifdef here?
}
void flush_thread(void)
--
2.25.1
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
Re: [PATCH -next] powerpc/smp: Remove unused inline functions
Le 11/03/2022 à 13:51, YueHaibing a écrit :
> commit 441c19c8a290 ("powerpc/kvm/book3s_hv: Rework the secondary inhibit
> code")
> left behind this, so can remove it.
>
> Signed-off-by: YueHaibing
> Reviewed-by: Daniel Axtens
Reviewed-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/smp.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index 60ab739a5e3b..f63505d74932 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -189,8 +189,6 @@ extern void __cpu_die(unsigned int cpu);
> #define smp_setup_cpu_maps()
> #define thread_group_shares_l2 0
> #define thread_group_shares_l3 0
> -static inline void inhibit_secondary_onlining(void) {}
> -static inline void uninhibit_secondary_onlining(void) {}
> static inline const struct cpumask *cpu_sibling_mask(int cpu)
> {
> return cpumask_of(cpu);
Re: [PATCH -next] powerpc/kuap: Remove unused inline function __kuap_assert_locked()
Le 11/03/2022 à 14:00, YueHaibing a écrit :
> commit 2341964e27b0 ("powerpc/kuap: Remove __kuap_assert_locked()")
> left behind this one, remove it.
>
> Signed-off-by: YueHaibing
Thanks for fixing this
Acked-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/kup.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
> index fb2237809d63..d751ddd08110 100644
> --- a/arch/powerpc/include/asm/kup.h
> +++ b/arch/powerpc/include/asm/kup.h
> @@ -52,7 +52,6 @@ __bad_kuap_fault(struct pt_regs *regs, unsigned long
> address, bool is_write)
> return false;
> }
>
> -static inline void __kuap_assert_locked(void) { }
> static inline void __kuap_lock(void) { }
> static inline void __kuap_save_and_lock(struct pt_regs *regs) { }
> static inline void kuap_user_restore(struct pt_regs *regs) { }
[PATCH v1] powerpc: Use static call for get_irq()
__do_irq() inconditionnaly calls ppc_md.get_irq()
That's definitely a hot path.
At the time being ppc_md.get_irq address is read every time
from ppc_md structure.
Replace that call by a static call, and initialise that
call after ppc_md.init_IRQ() has set ppc_md.get_irq.
Emit a warning and don't set the static call if ppc_md.init_IRQ()
is still NULL, that way the kernel won't blow up if for some
reason ppc_md.get_irq() doesn't get properly set.
With the patch:
<__SCT__ppc_get_irq>:
0: 48 00 00 20 b 20 <__static_call_return0> <==
Replaced by 'b ' at runtime
...
0020 <__static_call_return0>:
20: 38 60 00 00 li r3,0
24: 4e 80 00 20 blr
...
0058 <__do_irq>:
...
64: 48 00 00 01 bl 64 <__do_irq+0xc>
64: R_PPC_REL24 __SCT__ppc_get_irq
68: 2c 03 00 00 cmpwi r3,0
...
Before the patch:
0038 <__do_irq>:
...
3c: 3d 20 00 00 lis r9,0
3e: R_PPC_ADDR16_HA ppc_md+0x1c
...
44: 81 29 00 00 lwz r9,0(r9)
46: R_PPC_ADDR16_LO ppc_md+0x1c
...
4c: 7d 29 03 a6 mtctr r9
50: 4e 80 04 21 bctrl
54: 2c 03 00 00 cmpwi r3,0
...
On PPC64 which doesn't implement static calls yet we get:
00d0 <__do_irq>:
...
dc: 00 00 22 3d addis r9,r2,0
dc: R_PPC64_TOC16_HA.data+0x8
...
e4: 00 00 89 e9 ld r12,0(r9)
e4: R_PPC64_TOC16_LO_DS .data+0x8
...
f0: a6 03 89 7d mtctr r12
f4: 18 00 41 f8 std r2,24(r1)
f8: 21 04 80 4e bctrl
fc: 18 00 41 e8 ld r2,24(r1)
...
So on PPC64 that's similar to what we get without static calls.
But at least until ppc_md.get_irq() is set the call is to
__static_call_return0.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 752fb182eacb..1c4715a03cd1 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -730,6 +731,8 @@ static __always_inline void call_do_irq(struct pt_regs
*regs, void *sp)
);
}
+DEFINE_STATIC_CALL_RET0(ppc_get_irq, *ppc_md.get_irq);
+
void __do_irq(struct pt_regs *regs)
{
unsigned int irq;
@@ -741,7 +744,7 @@ void __do_irq(struct pt_regs *regs)
*
* This will typically lower the interrupt line to the CPU
*/
- irq = ppc_md.get_irq();
+ irq = static_call(ppc_get_irq)();
/* We can hard enable interrupts now to allow perf interrupts */
if (should_hard_irq_enable())
@@ -809,6 +812,9 @@ void __init init_IRQ(void)
if (ppc_md.init_IRQ)
ppc_md.init_IRQ();
+
+ if (!WARN_ON(!ppc_md.get_irq))
+ static_call_update(ppc_get_irq, ppc_md.get_irq);
}
#ifdef CONFIG_BOOKE_OR_40x
--
2.34.1
Re: [PATCH net-next v2] powerpc/net: Implement powerpc specific csum_shift() to remove branch
Hello: This patch was applied to netdev/net-next.git (master) by David S. Miller : On Tue, 8 Mar 2022 17:12:10 +0100 you wrote: > Today's implementation of csum_shift() leads to branching based on > parity of 'offset' > > 02f8 : >2f8: 70 a5 00 01 andi. r5,r5,1 >2fc: 41 a2 00 08 beq 304 >300: 54 84 c0 3e rotlwi r4,r4,24 >304: 7c 63 20 14 addcr3,r3,r4 >308: 7c 63 01 94 addze r3,r3 >30c: 4e 80 00 20 blr > > [...] Here is the summary with links: - [net-next,v2] powerpc/net: Implement powerpc specific csum_shift() to remove branch https://git.kernel.org/netdev/net-next/c/3af722cb735d You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
