Hi,
Le 22/05/2018 à 10:23, Pingfan Liu a écrit :
> For kexec -p, the boot cpu can be not the cpu0, this causes the problem
> to alloc paca[]. In theory, there is no requirement to assign cpu's logical
> id as its present seq by device tree. But we have something like
> cpu_first_thread_sibling(),
Le 19/06/2023 à 04:49, Sourabh Jain a écrit :
> Move update_cpus_node and get_crash_memory_ranges functions from
> kexec/file_load_64.c to kexec/core_64.c to make these functions usable
> by other kexec components.
>
> Later in the series, these functions are utilized to do in-kernel update
>
il.
Christophe
>
> -Original Message-
> From: Pingfan Liu
> Sent: Monday, September 25, 2023 2:54 AM
> To: linuxppc-...@lists.ozlabs.org
> Cc: Pingfan Liu ; Michael Ellerman ;
> Nicholas Piggin ; Christophe Leroy
> ; Mahesh Salgaonkar ; Wen
> Xiong ; Baoqu
Le 29/05/2022 à 08:56, Uwe Kleine-König a écrit :
> Hello,
>
> on current linux-next ARCH=riscv allmodconfig breaks with:
>
>CC arch/riscv/kernel/elf_kexec.o
> arch/riscv/kernel/elf_kexec.c:345:5: error: redefinition of
> ‘arch_kexec_apply_relocations_add’
>345 | int
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
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
Le 11/12/2021 à 18:53, David Laight a écrit :
> From: Tiezhu Yang
>> Sent: 11 December 2021 03:33
>>
>> v2:
>>-- add copy_to_user_or_kernel() in lib/usercopy.c
>>-- define userbuf as bool type
>
> Instead of having a flag to indicate whether the buffer is user or kernel,
> would it be
Le 11/12/2021 à 04:33, Tiezhu Yang a écrit :
> In arch/*/kernel/crash_dump*.c, there exist many similar code
> about copy_oldmem_page(), remove copy_to() in fs/proc/vmcore.c
> and add copy_to_user_or_kernel() in lib/usercopy.c, then we can
> use copy_to_user_or_kernel() to simplify the related
Le 10/12/2021 à 17:59, Andrew Morton a écrit :
> On Fri, 10 Dec 2021 21:36:00 +0800 Tiezhu Yang wrote:
>
>> In arch/*/kernel/crash_dump*.c, there exist similar code about
>> copy_oldmem_page(), move copy_to() from vmcore.c to uaccess.h,
>> and then we can use copy_to() to simplify the related
Hi Scott,
Le 23/10/2015 à 05:54, Scott Wood a écrit :
Use an AS=1 trampoline TLB entry to allow all normal TLB1 entries to
be loaded at once. This avoids the need to keep the translation that
code is executing from in the same TLB entry in the final TLB
configuration as during early boot,
Le 15/09/2021 à 12:08, Borislav Petkov a écrit :
On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote:
I don't love it, a new C file and an out-of-line call to then call back
to a static inline that for most configuration will return false ... but
whatever :)
Yeah, hch thinks
Le 14/09/2021 à 13:58, Borislav Petkov a écrit :
On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only
On 9/8/21 10:58 PM, Tom Lendacky wrote:
Introduce a powerpc version of the cc_platform_has() function. This will
be used to replace the powerpc mem_encrypt_active() implementation, so
the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
attribute.
Cc: Michael Ellerman
Cc:
On 9/8/21 10:58 PM, Tom Lendacky wrote:
In prep for other confidential computing technologies, introduce a generic
helper function, cc_platform_has(), that can be used to check for specific
I have little problem with that naming.
For me CC has always meant Compiler Collection.
active
On 9/8/21 10:58 PM, Tom Lendacky wrote:
diff --git a/arch/powerpc/include/asm/mem_encrypt.h
b/arch/powerpc/include/asm/mem_encrypt.h
index ba9dab07c1be..2f26b8fc8d29 100644
--- a/arch/powerpc/include/asm/mem_encrypt.h
+++ b/arch/powerpc/include/asm/mem_encrypt.h
@@ -10,11 +10,6 @@
Le 28/07/2021 à 00:26, Tom Lendacky a écrit :
Replace occurrences of mem_encrypt_active() with calls to prot_guest_has()
with the PATTR_MEM_ENCRYPT attribute.
What about
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210730114231.23445-1-w...@kernel.org/ ?
Christophe
Cc:
Le 26/06/2020 à 21:04, Hari Bathini a écrit :
Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
same spirit.
At the time being,
Le 26/06/2020 à 21:04, Hari Bathini a écrit :
Some archs can have special memory regions, within the given memory
range, which can't be used for the buffer in a kexec segment. As
kexec_add_buffer() function is being called from generic code as well,
add weak arch_kexec_add_buffer definition
Le 28/02/2020 à 06:53, Pingfan Liu a écrit :
At present, plpar_hcall(H_SCM_BIND_MEM, ...) takes a very long time, so
if dumping to fsdax, it will take a very long time.
Take a closer look, during the papr_scm initialization, the only
configuration is through drc_pmem_bind()->
Le 28/02/2020 à 06:53, Pingfan Liu a écrit :
Since new_property() is used in several calling sites, splitting it out for
reusing.
To ease the review, although the split out part has coding style issue,
keeping it untouched and fixed in next patch.
The moved function fits in one screen. I
Le 10/07/2019 à 16:29, Sven Schnelle a écrit :
It had only one definition, so just use the function directly.
It had only one definition because it was for ppc64 only.
But as far as I understand (at least from the name of the new file), you
want it to be generic, don't you ? Therefore I get
Le 10/07/2019 à 16:29, Sven Schnelle a écrit :
It wasn't used anywhere, so lets drop it.
And also, it is already defined in asm-generic/module.h
Signed-off-by: Sven Schnelle
Reviewed-by: Christophe Leroy
---
kernel/kexec_elf.c | 4
1 file changed, 4 deletions(-)
diff --git
Le 10/07/2019 à 16:29, Sven Schnelle a écrit :
base was never unsigned, so we can remove it.
Do you mean never assigned ?
Signed-off-by: Sven Schnelle
Reviewed-by: Christophe Leroy
---
kernel/kexec_elf.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
Hi Sven,
On 07/09/2019 07:43 PM, Sven Schnelle wrote:
Right now powerpc provides an implementation to read elf files
with the kexec_file() syscall. Make that available as a public
kexec interface so it can be re-used on other architectures.
Signed-off-by: Sven Schnelle
---
arch/Kconfig
Hi Sven,
Le 08/07/2019 à 12:06, Christophe Leroy a écrit :
From: Sven Schnelle
Please describe you patch.
All the changes you are doing to the ppc64 version in order to make it
generic should be described.
Those changes are also maybe worth splitting the patch in several parts,
either
Le 07/07/2019 à 21:21, Sven Schnelle a écrit :
Signed-off-by: Sven Schnelle
---
Please add here a description of the changes done since RFC.
arch/Kconfig | 3 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/kexec_elf_64.c | 547
From: Sven Schnelle
Signed-off-by: Sven Schnelle
---
patch generated with 'git format-patch -C' in order to
see the modifications done in kexec_elf.c in addition to
copying it from arch/powerpc/kernel/kexec_elf_64.c
arch/Kconfig | 3 +
Hi Sven,
On 06/25/2019 06:54 PM, Sven Schnelle wrote:
Hi List,
i recently started working on kexec for PA-RISC. While doing so, i figured
that powerpc already has support for reading ELF images inside of the Kernel.
My first attempt was to steal the source code and modify it for PA-RISC, but
28 matches
Mail list logo
