Hi All,
I am sorry for the delay. I was away for my Diwali holidays and came
back to office today.
On Tue, Nov 6, 2018 at 2:14 PM Ard Biesheuvel wrote:
>
> On 6 November 2018 at 02:30, Will Deacon wrote:
> > On Fri, Nov 02, 2018 at 02:44:10AM +0530, Bhupesh Sharma wrote:
> >> With the latest
The memblock arrays can be resized dynamically if needed, but this is
only done after memblock_allow_resize() is called, since it is up to
the architecture to decide at which point doing so is possible (i.e.,
when all the memory that memblock describes is actually mapped)
ARM grants this
The new memory EFI reservation feature we introduced to allow memory
reservations to persist across kexec may trigger an unbounded number
of calls to memblock_reserve(). The memblock subsystem can deal with
this fine, but not before memblock resizing is enabled, which we can
only do after
In preparation of updating efi_mem_reserve_persistent() to cause less
fragmentation when dealing with many persistent reservations, update
the struct definition and the code that handles it currently so it
can describe an arbitrary number of reservations using a single linked
list entry. The
early_memremap() and early_ioremap() rely on early fixmap support,
which shares its virtual address space with kmap(), and so it is
taken down in paging_init().
In order to permit the EFI persistent memory reservation code to
use early_memremap() when called from paging_init(), move the call
to
This series addresses the kexec/kdump crash on arm64 system with many CPUs
that was reported by Bhupesh.
Patch #1 fixes the actual crash, but may result in memblock_reserve() to
fail. This is fixed in patch #4, where the point that the persistent
reservations are applied is moved to after
The current implementation of efi_mem_reserve_persistent() is rather
naive, in the sense that for each invocation, it creates a separate
linked list entry to describe the reservation. Since the linked list
entries themselves need to persist across subsequent kexec reboots,
every reservation
Bhupesh reports that having numerous memblock reservations at early
boot may result in the following crash:
Unable to handle kernel paging request at virtual address 80003ffe
...
Call trace:
__memcpy+0x110/0x180
memblock_add_range+0x134/0x2e8
memblock_reserve+0x70/0xb8
On Wed, Nov 07, 2018 at 11:04:53AM +0100, Ard Biesheuvel wrote:
> On 7 November 2018 at 10:58, Russell King - ARM Linux
> wrote:
> > On Wed, Nov 07, 2018 at 09:51:09AM +, Marc Zyngier wrote:
> >> On 06/11/18 23:49, Russell King - ARM Linux wrote:
> >> > On Tue, Nov 06, 2018 at 09:06:56PM
On 7 November 2018 at 10:58, Russell King - ARM Linux
wrote:
> On Wed, Nov 07, 2018 at 09:51:09AM +, Marc Zyngier wrote:
>> On 06/11/18 23:49, Russell King - ARM Linux wrote:
>> > On Tue, Nov 06, 2018 at 09:06:56PM +0100, Ard Biesheuvel wrote:
>> >> On 6 November 2018 at 20:08, Russell King -
On Wed, Nov 07, 2018 at 09:51:09AM +, Marc Zyngier wrote:
> On 06/11/18 23:49, Russell King - ARM Linux wrote:
> > On Tue, Nov 06, 2018 at 09:06:56PM +0100, Ard Biesheuvel wrote:
> >> On 6 November 2018 at 20:08, Russell King - ARM Linux
> >> wrote:
> >>> On Tue, Nov 06, 2018 at 08:02:58PM
On 06/11/18 23:49, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2018 at 09:06:56PM +0100, Ard Biesheuvel wrote:
>> On 6 November 2018 at 20:08, Russell King - ARM Linux
>> wrote:
>>> On Tue, Nov 06, 2018 at 08:02:58PM +0100, Ard Biesheuvel wrote:
On 6 November 2018 at 12:37, Ard
12 matches
Mail list logo
