[PATCH v8 3/3] Documentation/powerpc: update fadump implementation details

2024-02-16 Thread Sourabh Jain
The patch titled ("powerpc: make fadump resilient with memory add/remove events") has made significant changes to the implementation of fadump, particularly on elfcorehdr creation and fadump crash info header structure. Therefore, updating the fadump implementation documentation to reflect those

[PATCH v8 2/3] powerpc/fadump: add hotplug_ready sysfs interface

2024-02-16 Thread Sourabh Jain
The elfcorehdr describes the CPUs and memory of the crashed kernel to the kernel that captures the dump, known as the second or fadump kernel. The elfcorehdr needs to be updated if the system's memory changes due to memory hotplug or online/offline events. Currently, memory hotplug events are

[PATCH v8 1/3] powerpc: make fadump resilient with memory add/remove events

2024-02-16 Thread Sourabh Jain
Due to changes in memory resources caused by either memory hotplug or online/offline events, the elfcorehdr, which describes the CPUs and memory of the crashed kernel to the kernel that collects the dump (known as second/fadump kernel), becomes outdated. Consequently, attempting dump collection

[PATCH v8 0/3] powerpc: make fadump resilient with memory add/remove events

2024-02-16 Thread Sourabh Jain
Problem: Due to changes in memory resources caused by either memory hotplug or online/offline events, the elfcorehdr, which describes the cpus and memory of the crashed kernel to the kernel that collects the dump (known as second/fadump kernel), becomes outdated. Consequently, attempting

Re: [kvm-unit-tests PATCH v4 8/8] migration: add a migration selftest

2024-02-16 Thread Nicholas Piggin
On Fri Feb 16, 2024 at 9:15 PM AEST, Thomas Huth wrote: > On 09/02/2024 10.11, Nicholas Piggin wrote: > > Add a selftest for migration support in guest library and test harness > > code. It performs migrations in a tight loop to irritate races and bugs > > in the test harness code. > > > >

Re: [PATCH v2] MAINTAINERS: adjust file entries after crypto vmx file movement

2024-02-16 Thread Herbert Xu
On Thu, Feb 08, 2024 at 10:33:27AM +0100, Lukas Bulwahn wrote: > Commit 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") moves the > crypto vmx files to arch/powerpc, but misses to adjust the file entries for > IBM Power VMX Cryptographic instructions and LINUX FOR POWERPC. > > Hence,

Re: [PATCH] powerpc: remove unused *_syscall_64.o variables in Makefile

2024-02-16 Thread Masahiro Yamada
+To: Daniel Axtens Maybe, we should check if the issue fixed by 2f26ed1764b42a8c40d9c48441c73a70d805decf came back. On Fri, Feb 16, 2024 at 10:55 PM Masahiro Yamada wrote: > > Commit ab1a517d55b0 ("powerpc/syscall: Rename syscall_64.c into > interrupt.c") missed to update these three

Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings

2024-02-16 Thread John Hubbard
On 2/16/24 08:56, Catalin Marinas wrote: ... The problem is that the contpte_* symbols are called from the ptep_* inline functions. So where those inlines are called from modules, we need to make sure the contpte_* symbols are available. John Hubbard originally reported this problem against v1

Re: [PATCH v2] powerpc: Add gpr1 and fpu save/restore functions

2024-02-16 Thread Timothy Pearson
- Original Message - > From: "christophe leroy" > To: "Timothy Pearson" , "linuxppc-dev" > > Sent: Tuesday, February 13, 2024 9:13:41 AM > Subject: Re: [PATCH v2] powerpc: Add gpr1 and fpu save/restore functions > Le 12/02/2024 à 18:14, Timothy Pearson a écrit : > All this looks very

[PATCH v3] powerpc: Add gpr1 and fpu save/restore functions

2024-02-16 Thread Timothy Pearson
When building the kernel in size optimized mode with the amdgpu module enabled, gcc will begin referencing external gpr1 and fpu save/restore functions. This will then cause a linker failure as we do not link against libgcc which normally contains those builtin functions. Implement gpr1 and fpu

Re: [PATCH] KVM: Get rid of return value from kvm_arch_create_vm_debugfs()

2024-02-16 Thread Marc Zyngier
On Fri, 16 Feb 2024 15:59:41 +, Oliver Upton wrote: > > The general expectation with debugfs is that any initialization failure > is nonfatal. Nevertheless, kvm_arch_create_vm_debugfs() allows > implementations to return an error and kvm_create_vm_debugfs() allows > that to fail VM creation.

Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings

2024-02-16 Thread Catalin Marinas
On Fri, Feb 16, 2024 at 12:53:43PM +, Ryan Roberts wrote: > On 16/02/2024 12:25, Catalin Marinas wrote: > > On Thu, Feb 15, 2024 at 10:31:59AM +, Ryan Roberts wrote: > >> arch/arm64/mm/contpte.c | 285 +++ > > > > Nitpick: I think most symbols in

[PATCH] KVM: Get rid of return value from kvm_arch_create_vm_debugfs()

2024-02-16 Thread Oliver Upton
The general expectation with debugfs is that any initialization failure is nonfatal. Nevertheless, kvm_arch_create_vm_debugfs() allows implementations to return an error and kvm_create_vm_debugfs() allows that to fail VM creation. Change to a void return to discourage architectures from making

Re: [kvm-unit-tests PATCH v1 00/18] arm/arm64: Rework cache maintenance at boot

2024-02-16 Thread Alexandru Elisei
Hi, On Thu, Nov 30, 2023 at 04:07:02AM -0500, Shaoqin Huang wrote: > Hi, > > I'm posting Alexandru's patch set[1] rebased on the latest branch with the > conflicts being resolved. No big changes compare to its original code. > > As this version 1 of this series was posted one years ago, I would

Re: [PATCH v1 4/5] powerpc: Remove cpu-as-y completely

2024-02-16 Thread Christophe Leroy
Le 20/02/2023 à 07:00, Michael Ellerman a écrit : > Christophe Leroy writes: >> cpu-as-y is there to force assembler building options. >> But there is no need for that. Gcc is passed the necessary >> options and it automatically pass the appropriate option to >> GAS. >> >> GCC is given

Re: [PATCH v2 0/2] PCI endpoint BAR hardware description cleanup

2024-02-16 Thread Manivannan Sadhasivam
On Fri, Feb 16, 2024 at 02:45:13PM +0100, Niklas Cassel wrote: > The series is based on top of: > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint > > > Hello all, > > This series cleans up the hardware description for PCI endpoint BARs. > > The problems with the

Re: [PATCH v2 1/2] PCI: endpoint: Clean up hardware description for BARs

2024-02-16 Thread Manivannan Sadhasivam
On Fri, Feb 16, 2024 at 02:45:14PM +0100, Niklas Cassel wrote: > The hardware description for BARs is scattered in many different variables > in pci_epc_features. Some of these things are mutually exclusive, so it > can create confusion over which variable that has precedence over another. > >

Re: [kvm-unit-tests PATCH v4 8/8] migration: add a migration selftest

2024-02-16 Thread Thomas Huth
On 09/02/2024 10.11, Nicholas Piggin wrote: Add a selftest for migration support in guest library and test harness code. It performs migrations in a tight loop to irritate races and bugs in the test harness code. Include the test in arm, s390, powerpc. Acked-by: Claudio Imbrenda (s390x)

[powerpc:merge] BUILD SUCCESS 35d5936fc3d416d9629c6b53a07bd25dc1c2bc7f

2024-02-16 Thread kernel test robot
allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc haps_hs_smp_defconfig gcc arc randconfig-001-20240216 gcc arc randconfig-002

[PATCH] powerpc: remove unused KCSAN_SANITIZE_early_64.o in Makefile

2024-02-16 Thread Masahiro Yamada
Commit 2fb857bc9f9e ("powerpc/kcsan: Add exclusions from instrumentation") added KCSAN_SANITIZE_early_64.o to arch/powerpc/kernel/Makefile, while it does not compile early_64.o. Signed-off-by: Masahiro Yamada --- arch/powerpc/kernel/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] powerpc: remove unused *_syscall_64.o variables in Makefile

2024-02-16 Thread Masahiro Yamada
Commit ab1a517d55b0 ("powerpc/syscall: Rename syscall_64.c into interrupt.c") missed to update these three lines: GCOV_PROFILE_syscall_64.o := n KCOV_INSTRUMENT_syscall_64.o := n UBSAN_SANITIZE_syscall_64.o := n To restore the original behavior, we could replace them with:

[PATCH v2 1/2] PCI: endpoint: Clean up hardware description for BARs

2024-02-16 Thread Niklas Cassel
The hardware description for BARs is scattered in many different variables in pci_epc_features. Some of these things are mutually exclusive, so it can create confusion over which variable that has precedence over another. Improve the situation by creating a struct pci_epc_bar_desc, and a new enum

[PATCH v2 0/2] PCI endpoint BAR hardware description cleanup

2024-02-16 Thread Niklas Cassel
The series is based on top of: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint Hello all, This series cleans up the hardware description for PCI endpoint BARs. The problems with the existing hardware description: -The documentation is lackluster. -Some of the names

Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings

2024-02-16 Thread Ryan Roberts
Hi Catalin, Thanks for the review! Comments below... On 16/02/2024 12:25, Catalin Marinas wrote: > On Thu, Feb 15, 2024 at 10:31:59AM +, Ryan Roberts wrote: >> arch/arm64/mm/contpte.c | 285 +++ > > Nitpick: I think most symbols in contpte.c can be

Re: [PATCH v6 18/18] arm64/mm: Automatically fold contpte mappings

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:32:05AM +, Ryan Roberts wrote: > There are situations where a change to a single PTE could cause the > contpte block in which it resides to become foldable (i.e. could be > repainted with the contiguous bit). Such situations arise, for example, > when user space

Re: [PATCH v6 17/18] arm64/mm: __always_inline to improve fork() perf

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:32:04AM +, Ryan Roberts wrote: > As set_ptes() and wrprotect_ptes() become a bit more complex, the > compiler may choose not to inline them. But this is critical for fork() > performance. So mark the functions, along with contpte_try_unfold() > which is called by

Re: [PATCH v6 16/18] arm64/mm: Implement pte_batch_hint()

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:32:03AM +, Ryan Roberts wrote: > When core code iterates over a range of ptes and calls ptep_get() for > each of them, if the range happens to cover contpte mappings, the number > of pte reads becomes amplified by a factor of the number of PTEs in a > contpte block.

Re: [PATCH v6 14/18] arm64/mm: Implement new [get_and_]clear_full_ptes() batch APIs

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:32:01AM +, Ryan Roberts wrote: > Optimize the contpte implementation to fix some of the > exit/munmap/dontneed performance regression introduced by the initial > contpte commit. Subsequent patches will solve it entirely. > > During exit(), munmap() or

Re: [PATCH v6 13/18] arm64/mm: Implement new wrprotect_ptes() batch API

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:32:00AM +, Ryan Roberts wrote: > Optimize the contpte implementation to fix some of the fork performance > regression introduced by the initial contpte commit. Subsequent patches > will solve it entirely. > > During fork(), any private memory in the parent must be

Re: [PATCH v6 12/18] arm64/mm: Wire up PTE_CONT for user mappings

2024-02-16 Thread Catalin Marinas
On Thu, Feb 15, 2024 at 10:31:59AM +, Ryan Roberts wrote: > arch/arm64/mm/contpte.c | 285 +++ Nitpick: I think most symbols in contpte.c can be EXPORT_SYMBOL_GPL(). We don't expect them to be used by random out of tree modules. In fact, do we expect them

Re: [PATCH 1/2] PCI: endpoint: Clean up hardware description for BARs

2024-02-16 Thread Manivannan Sadhasivam
On Fri, Feb 16, 2024 at 04:49:08PM +0530, Manivannan Sadhasivam wrote: > On Sat, Feb 10, 2024 at 02:26:25AM +0100, Niklas Cassel wrote: > > The hardware description for BARs is scattered in many different variables > > in pci_epc_features. Some of these things are mutually exclusive, so it > > can

Re: [PATCH 1/2] PCI: endpoint: Clean up hardware description for BARs

2024-02-16 Thread Manivannan Sadhasivam
On Sat, Feb 10, 2024 at 02:26:25AM +0100, Niklas Cassel wrote: > The hardware description for BARs is scattered in many different variables > in pci_epc_features. Some of these things are mutually exclusive, so it > can create confusion over which variable that has precedence over another. > >

Re: [kvm-unit-tests PATCH v4 8/8] migration: add a migration selftest

2024-02-16 Thread Thomas Huth
On 09/02/2024 10.11, Nicholas Piggin wrote: Add a selftest for migration support in guest library and test harness code. It performs migrations in a tight loop to irritate races and bugs in the test harness code. Include the test in arm, s390, powerpc. Acked-by: Claudio Imbrenda (s390x)

[PATCH 2/2] powerpc: Don't ignore errors from set_memory_{n}p() in __kernel_map_pages()

2024-02-16 Thread Christophe Leroy
set_memory_p() and set_memory_np() can fail. As mentioned in linux/mm.h: /* * To support DEBUG_PAGEALLOC architecture must ensure that * __kernel_map_pages() never fails */ So panic in case set_memory_p() or set_memory_np() fail in __kernel_map_pages(). Link:

[PATCH 1/2] powerpc: Refactor __kernel_map_pages()

2024-02-16 Thread Christophe Leroy
__kernel_map_pages() is almost identical for PPC32 and RADIX. Refactor it. On PPC32 it is not needed for KFENCE, but to keep it simple just make it similar to PPC64. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/64/pgtable.h | 10 --

[PATCH] powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx()

2024-02-16 Thread Christophe Leroy
mark_rodata_ro() and mark_initmem_nx() use functions that can fail like set_memory_nx() and set_memory_ro(), leading to a not protected kernel. In case of failure, panic. Link: https://github.com/KSPP/linux/issues/7 Signed-off-by: Christophe Leroy --- arch/powerpc/mm/book3s32/mmu.c | 7 --

[PATCH] powerpc/kprobes: Handle error returned by set_memory_rox()

2024-02-16 Thread Christophe Leroy
set_memory_rox() can fail. In case it fails, free allocated memory and return NULL. Link: https://github.com/KSPP/linux/issues/7 Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/kprobes.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git

[PATCH] powerpc: Implement set_memory_rox()

2024-02-16 Thread Christophe Leroy
Same as x86 and s390, add set_memory_rox() to avoid doing one pass with set_memory_ro() and a second pass with set_memory_x(). See commit 60463628c9e0 ("x86/mm: Implement native set_memory_rox()") and commit 22e99fa56443 ("s390/mm: implement set_memory_rox()") for more information.

[PATCH] powerpc: Use user_mode() macro when possible

2024-02-16 Thread Christophe Leroy
There is a nice macro to check user mode. Use it instead of open coding anding with MSR_PR to increase readability and avoid having to comment what that anding is for. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/interrupt.h | 2 +- arch/powerpc/kernel/syscall.c| 2 +-

[PATCH] powerpc/trace: Restrict hash_fault trace event to HASH MMU

2024-02-16 Thread Christophe Leroy
'perf list' on powerpc 8xx shows an event named "1:hash_fault". This event is pointless because trace_hash_fault() is called only from mm/book3s64/hash_utils.c Only define it when CONFIG_PPC_64S_HASH_MMU is selected. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/trace.h | 3 ++-