Hi,
On 12/3/19 7:47 PM, Nicolas Saenz Julienne wrote:
Some users need to make sure their rounding function accepts and returns
64bit long variables regardless of the architecture. Sadly
roundup/rounddown_pow_two() takes and returns unsigned longs. It turns
out ilog2() already handles 32/64bit
Hi Pingfan,
Thank you for the patch.
> -Original Message-
> since the following commit, -lebl has been removed from elfutils.
> commit b833c731359af12af9f16bcb621b3cdc170eafbc
> Author: Mark Wielaard
> Date: Thu Aug 29 23:34:11 2019 +0200
>
> libebl: Don't install libebl.a,
On 11/14/2019 10:45 AM, AKASHI Takahiro wrote:
Enabling crash dump (kdump) includes
* prepare contents of ELF header of a core dump file, /proc/vmcore,
using crash_prepare_elf64_headers(), and
* add two device tree properties, "linux,usable-memory-range" and
"linux,elfcorehdr", which
Hi Akashi,
On 11/14/2019 10:45 AM, AKASHI Takahiro wrote:
In the implementation of kexec_file_load-based kdump for arm64,
fdt_appendprop_addrrange() will be used, but fdt_addresses.c
will fail to compile due to missing UINT32_MAX.
So just define it in libfdt_env.h.
Signed-off-by: AKASHI
Hi Akashi,
Thanks for the patchset.
On 11/14/2019 10:45 AM, AKASHI Takahiro wrote:
This is the last piece of my kexec_file_load implementation for arm64.
It is now ready for being merged as some relevant patch to dtc/libfdt[1]
has finally been integrated in v5.3-rc1.
(Nothing changed since
Hello Masa,
(+Cc Simon)
On Thu, Dec 5, 2019 at 12:27 AM Masayoshi Mizuma wrote:
>
> On Wed, Dec 04, 2019 at 06:17:59PM +, James Morse wrote:
> > Hi Masa,
> >
> > On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > > Thank you for sending the patch, but unfortunately it doesn't work for
> > >
On Wed, Dec 04, 2019 at 06:17:59PM +, James Morse wrote:
> Hi Masa,
>
> On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> > Thank you for sending the patch, but unfortunately it doesn't work for the
> > issue...
> >
> > After applied your patch, the LPI tables are marked as reserved in
> >
Hi Masa,
On 04/12/2019 17:17, Masayoshi Mizuma wrote:
> Thank you for sending the patch, but unfortunately it doesn't work for the
> issue...
>
> After applied your patch, the LPI tables are marked as reserved in
> /proc/iomem like as:
>
> 8030-a1fd : System RAM
> 8048-8134 :
> -Original Message-
> This patch marks '--mem-usage' option as unsupported for arm64
> architecture.
>
> With the newer arm64 kernels supporting 48-bit/52-bit VA address spaces
> and keeping a single binary for supporting the same, the address of
> kernel symbols like _stext which could
> -Original Message-
> With ARMv8.2-LVA architecture extension availability, arm64 hardware
> which supports this extension can support upto 52-bit virtual
> addresses. It is specially useful for having a 52-bit user-space virtual
> address space while the kernel can still retain
> -Original Message-
> ARMv8.2-LPA architecture extension (if available on underlying hardware)
> can support 52-bit physical addresses, while the kernel virtual
> addresses remain 48-bit.
>
> Make sure that we read the 52-bit PA address capability from
> 'MAX_PHYSMEM_BITS' variable (if
Hi Bhupesh,
Sorry for the late reply.
> -Original Message-
> This patch adds a common feature for archs (except arm64, for which
> similar support is added via subsequent patch) to retrieve
> 'MAX_PHYSMEM_BITS' from vmcoreinfo (if available).
We already have the calibrate_machdep_info()
Hello Ard,
Thank you for sending the patch, but unfortunately it doesn't work for the
issue...
After applied your patch, the LPI tables are marked as reserved in
/proc/iomem like as:
8030-a1fd : System RAM
8048-8134 : Kernel code
8135-817b : reserved
Configure a page table located in kexec-safe memory that has
the following mappings:
1. identity mapping for text of relocation function with executable
permission.
2. identity mapping for argument for relocation function.
3. linear mappings for all source ranges
4. linear mappings for all
Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
the following arguments:
head: start of array that contains relocation information.
entry: entry point for new kernel or purgatory.
dtb_mem:first and only argument to entry.
The number of
If we have a EL2 mode without VHE, the EL2 vectors are needed in order
to switch to EL2 and jump to new world with hyperivsor privileges.
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/kexec.h | 5 +
arch/arm64/kernel/asm-offsets.c | 1 +
x0 will contain the only argument to arm64_relocate_new_kernel; don't
use it as a temp. Reassigned registers to free-up x0.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/relocate_kernel.S | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
Now, that relocation is done using virtual addresses, reloc_arg->head
is not needed anymore.
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/kexec.h| 2 --
arch/arm64/kernel/asm-offsets.c | 1 -
arch/arm64/kernel/machine_kexec.c | 1 -
3 files changed, 4 deletions(-)
diff --git
Now, that we have transitional page tables configured, temporarily enable
MMU to allow faster relocation of segments to final destination.
The performance data: for a moderate size kernel + initramfs: 25M the
relocation was taking 0.382s, with enabled MMU it now takes
0.019s only or x20
Soon, relocation function will share the same page with EL2 vectors.
Add offset within this page to arm64_relocate_new_kernel, and also
the total size of relocation code which will include both the function
and the EL2 vectors.
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/kexec.h
Remove excessive empty lines from arm64_relocate_new_kernel.
Also, use comments on the same lines with instructions where
appropriate.
Change ENDPROC to END it never returns.
copy_page(dest, src, tmps...)
Increments dest and src by PAGE_SIZE, so no need to store dest
prior to calling copy_page
Currently, kernel relocation function is configured in machine_kexec()
at the time of kexec reboot by using control_code_page.
This operation, however, is more logical to be done during kexec_load,
and thus remove from reboot time. Move, setup of this function to
newly added
Change argument types from unsigned long to a more descriptive
phys_addr_t.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/cpu-reset.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index
Currently, kexec_image_info() is called during load time, and
right before kernel is being kexec'ed. There is no need to do both.
So, call it only once when segments are loaded and the physical
location of page with copy of arm64_relocate_new_kernel is known.
Signed-off-by: Pavel Tatashin
---
Make trans_pgd_create_copy and its subroutines to use allocator that is
passed as an argument
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/trans_pgd.h | 4 +--
arch/arm64/kernel/hibernate.c | 7 -
arch/arm64/mm/trans_pgd.c | 44 ++
3
kexec is going to use a different allocator, so make
trans_pgd_map_page to accept allocator as an argument, and also
kexec is going to use a different map protection, so also pass
it via argument.
Signed-off-by: Pavel Tatashin
Reviewed-by: Matthias Brugger
---
trans_pgd_* should be independent from mm context because the tables that
are created by this code are used when there are no mm context around, as
it is between kernels. Simply replace mm_init's with NULL.
Signed-off-by: Pavel Tatashin
---
arch/arm64/mm/trans_pgd.c | 12 ++--
1 file
Now, that we abstracted the required functions move them to a new home.
Later, we will generalize these function in order to be useful outside
of hibernation.
Signed-off-by: Pavel Tatashin
---
arch/arm64/Kconfig | 4 +
arch/arm64/include/asm/trans_pgd.h | 20 +++
trans_pgd_create_copy() and trans_pgd_map_page() are going to be
the basis for new shared code that handles page tables for cases
which are between kernels: kexec, and hibernate.
Note: Eventually, get_safe_page() will be moved into a function pointer
passed via argument, but for now keep it as
create_safe_exec_page() allocates a safe page and maps it at a
specific location, also this function returns the physical address
of newly allocated page.
The destination VA, and PA are specified in arguments: dst_addr,
phys_dst_addr
However, within the function it uses "dst" which has unsigned
There is PMD_SECT_RDONLY that is used in pud_* function which is confusing.
Signed-off-by: Pavel Tatashin
Acked-by: James Morse
---
arch/arm64/include/asm/pgtable-hwdef.h | 1 +
arch/arm64/kernel/hibernate.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
ttbr0 should be set to the beginning of pgdp, however, currently
in create_safe_exec_page it is set to pgdp after pgd_offset_raw(),
which works by accident.
Signed-off-by: Pavel Tatashin
Reviewed-by: James Morse
---
arch/arm64/kernel/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1
create_safe_exec_page() uses hibernate's allocator to create a set of page
table to map a single page that will contain the relocation code.
Remove the allocator related arguments, and use get_safe_page directly, as
it is done in other local functions in this file to simplify function
prototype.
Currently, dtb_mem is enabled only when CONFIG_KEXEC_FILE is
enabled. This adds ugly ifdefs to c files.
Always enabled dtb_mem, when it is not used, it is NULL.
Change the dtb_mem to phys_addr_t, as it is a physical address.
Signed-off-by: Pavel Tatashin
---
arch/arm64/include/asm/kexec.h|
Usually, gotos are used to handle cleanup after exception, but in case of
create_safe_exec_page and swsusp_arch_resume there are no clean-ups. So,
simply return the errors directly.
Signed-off-by: Pavel Tatashin
Reviewed-by: James Morse
---
arch/arm64/kernel/hibernate.c | 49
Many changes compared to version 6, so I decided to send it out now.
James Morse raised an important issue to which I do not have a solution
yet. But would like to discuss it.
---
https://lore.kernel.org/lkml/45a2f0b8-5bac-8b5d-d595-f92e9acb2...@arm.com
> + /* Map relocation function va == pa
It is the same as machine_kexec_prepare(), but is called after segments are
loaded. This way, can do processing work with already loaded relocation
segments. One such example is arm64: it has to have segments loaded in
order to create a page table, but it cannot do it during kexec time,
because at
The kexec_image_info() outputs all the necessary information about the
upcoming kexec. The extra debug printfs in machine_kexec() are not
needed.
Signed-off-by: Pavel Tatashin
---
arch/arm64/kernel/machine_kexec.c | 12
1 file changed, 12 deletions(-)
diff --git
Here is a regular kexec command sequence and output:
=
$ kexec --reuse-cmdline -i --load Image
$ kexec -e
[ 161.342002] kexec_core: Starting new kernel
Welcome to Buildroot
buildroot login:
=
Even when "quiet" kernel parameter is specified, "kexec_core: Starting
new kernel" is printed.
Memory regions that are reserved using efi_mem_reserve_persistent()
are recorded in a special EFI config table which survives kexec,
allowing the incoming kernel to honour them as well. However,
such reservations are not visible in /proc/iomem, and so the kexec
tools that load the incoming kernel
On 2019-12-04, Petr Mladek wrote:
>> +} else if ((DATA_WRAPS(data_ring, blk_lpos->begin) + 1 ==
>> +DATA_WRAPS(data_ring, blk_lpos->next)) ||
>> + ((DATA_WRAPS(data_ring, blk_lpos->begin) ==
>> + DATA_WRAPS(data_ring, -1UL)) &&
>> +
On Tue 2019-12-03 14:46:07, John Ogness wrote:
> On 2019-12-03, Petr Mladek wrote:
> >> Add the reader implementation for the new ringbuffer.
> >>
> >> Signed-off-by: John Ogness
> >> ---
> >> kernel/printk/printk_ringbuffer.c | 234 ++
> >>
Hello Dave,
On Wed, Dec 04, 2019 at 03:59:17PM +0800, Dave Young wrote:
> > Signed-off-by: Dave Young
> > ---
> > arch/x86/platform/efi/quirks.c |6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++
For the changes under drivers/net/ethernet/sfc:
Reviewed-by: Martin Habets
On 03/12/2019 11:47, Nicolas Saenz Julienne wrote:
> Some users need to make sure their rounding function accepts and returns
> 64bit long variables regardless of the architecture. Sadly
> roundup/rounddown_pow_two()
On Wed, 4 Dec 2019 at 10:14, Ingo Molnar wrote:
>
>
> * Dave Young wrote:
>
> > On 12/04/19 at 03:52pm, Dave Young wrote:
> > > Michael Weiser reported he got below error during a kexec rebooting:
> > > esrt: Unsupported ESRT version 2904149718861218184.
> > >
> > > The ESRT memory stays in EFI
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: af164898482817a1d487964b68f3c21bae7a1beb
Gitweb:
https://git.kernel.org/tip/af164898482817a1d487964b68f3c21bae7a1beb
Author:Dave Young
AuthorDate:Wed, 04 Dec 2019 15:52:33 +08:00
Committer:
* Dave Young wrote:
> On 12/04/19 at 03:52pm, Dave Young wrote:
> > Michael Weiser reported he got below error during a kexec rebooting:
> > esrt: Unsupported ESRT version 2904149718861218184.
> >
> > The ESRT memory stays in EFI boot services data, and it was reserved
> > in kernel via
* Dave Young wrote:
> On 12/04/19 at 03:52pm, Dave Young wrote:
> > Michael Weiser reported he got below error during a kexec rebooting:
> > esrt: Unsupported ESRT version 2904149718861218184.
> >
> > The ESRT memory stays in EFI boot services data, and it was reserved
> > in kernel via
On Tue, 3 Dec 2019 at 20:14, Masayoshi Mizuma wrote:
>
> From: Masayoshi Mizuma
>
> kexec reboot sometime fails in early boot sequence on aarch64 machine.
> That is because kexec overwrites the LPI property tables and pending
> tables with the initrd.
>
> To avoid the overwrite, introduce
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Masayoshi Mizuma
> Sent: Wednesday, December 4, 2019 5:14 AM
> To: Ard Biesheuvel ;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> Cc:
On 12/04/19 at 03:52pm, Dave Young wrote:
> Michael Weiser reported he got below error during a kexec rebooting:
> esrt: Unsupported ESRT version 2904149718861218184.
>
> The ESRT memory stays in EFI boot services data, and it was reserved
> in kernel via efi_mem_reserve(). The initial purpose
51 matches
Mail list logo
