nmi_exit(), so no need to
> - * rcu_read_lock().
> - */
> + rcu_read_lock();
> list_for_each_entry_rcu(ghes, _sea, list) {
> - ghes_proc(ghes);
> + if(!ghes_proc(ghes))
> + ret = 0;
> }
> +
tches a go a a TX2 box (one of the 224 CPU
ones...), and kexec worked just fine (v4.20-rc1 vanilla didn't manage to
kexec on this box).
There seem to be some additional userspace patches that are required for
the ACPI tables not to be corrupted in the secondary kernel, but that's
an orthogonal i
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
On Tue, 06 Nov 2018 19:01:51 +,
Ard Biesheuvel wrote:
>
> On 6 November 2018 at 19:27, Marc Zyngier wrote:
> > Hi Ard,
> >
> > On 06/11/18 11:37, Ard Biesheuvel wrote:
> >> This series addresses the kexec/kdump crash on arm64 system with many CPUs
On Fri, 21 Sep 2018 18:51:08 +0100,
Ard Biesheuvel wrote:
>
> On 21 September 2018 at 10:46, Marc Zyngier wrote:
> > On Fri, 21 Sep 2018 18:14:43 +0100,
> > Jeffrey Hugo wrote:
> >>
> >> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote:
> >> > Add s
On Fri, 21 Sep 2018 18:14:43 +0100,
Jeffrey Hugo wrote:
>
> On 9/21/2018 10:32 AM, Ard Biesheuvel wrote:
> > Add support for persistent memory reservations across kexec reboot on EFI
> > systems by introducing a Linux-specific UEFI configuration table that points
> > to a linked list in memory
Hi all,
On 27/09/18 09:50, Ard Biesheuvel wrote:
Thomas, Ingo,
Please pull/cherry-pick the below. Note that the first three patches will
be depended upon by an irqchip series that Marc Zyngier has sent out last
week, and that targets the next release as well. So please advise how to
proceed
On Tue, 02 Oct 2018 09:38:17 +0100,
Ingo Molnar wrote:
>
>
> * Ingo Molnar wrote:
>
> >
> > * Marc Zyngier wrote:
> >
> > > Hi all,
> > >
> > > On 27/09/18 09:50, Ard Biesheuvel wrote:
> > > > Thomas, Ingo,
> >
On 05/11/18 11:11, Ard Biesheuvel wrote:
> (+ Marc)
>
> On 1 November 2018 at 22:14, Bhupesh Sharma wrote:
>> Hi,
>>
>> With the latest EFI changes for memblock reservation across kdump
>> kernel from Ard (Commit 71e0940d52e107748b270213a01d3b1546657d74
>> ["efi: honour memory reservations
On Mon, 12 Nov 2018 02:45:48 +,
Qian Cai wrote:
>
>
>
> > On Nov 9, 2018, at 9:45 PM, Qian Cai wrote:
> >
> >
> > On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote:
> >
> >> Currently, efi_mem_reserve_persistent() may not be called from atomic
> >> context, since both the kmalloc() call and
On 20/11/2018 18:35, Ard Biesheuvel wrote:
> On Tue, 20 Nov 2018 at 19:29, Marc Zyngier wrote:
>>
>> Hi Ard,
>>
>> On 20/11/2018 17:35, Ard Biesheuvel wrote:
>>> Mapping the MEMRESERVE EFI configuration table from an early initcall
>>> is too lat
the handling of the initcalls.
>
> So instead, move the initialization performed by the initcall into
> efi_mem_reserve_persistent() itself.
>
> Signed-off-by: Ard Biesheuvel
I've just given it a go on one of my TX2s, and it boots just fine. So
for that:
Tested-by: Marc Zyngi
before we call the cache clean routines,
> resulting in undefined instruction exceptions if the firmware never
> enabled this bit.
>
> So set the bit explicitly in the EFI entry code.
>
> Cc: Marc Zyngier
> Signed-off-by: Ard Biesheuvel
> ---
> arch/arm/boot/compresse
On Sat, 30 Mar 2019 13:10:58 +,
Ard Biesheuvel wrote:
>
> On Sat, 30 Mar 2019 at 10:50, Marc Zyngier wrote:
> >
> > Hi Ard,
> >
> > On Fri, 29 Mar 2019 18:24:18 +,
> > Ard Biesheuvel wrote:
> > >
> > > The EFI stub is entered
On 07/04/2019 19:19, Ard Biesheuvel wrote:
> On Sun, 31 Mar 2019 at 10:47, Marc Zyngier wrote:
>>
>> On Sat, 30 Mar 2019 13:10:58 +,
>> Ard Biesheuvel wrote:
>>>
>>> On Sat, 30 Mar 2019 at 10:50, Marc Zyngier wrote:
>>>>
>>>>
On Thu, 14 Feb 2019 16:55:28 +,
Ard Biesheuvel wrote:
>
> On Thu, 14 Feb 2019 at 16:48, Marc Zyngier wrote:
> >
> > Hi Ard,
> >
> > On 13/02/2019 13:27, Ard Biesheuvel wrote:
> > > In the irqchip and EFI code, we have what basically amounts to a q
MEM_REGIONS] __initdata_memblock;
> #endif
> @@ -105,7 +111,7 @@ struct memblock memblock __initdata_memblock = {
>
> .reserved.regions = memblock_reserved_init_regions,
> .reserved.cnt = 1,/* empty dummy entry */
> - .reserved.max = INIT_MEMBLOCK_REGIONS,
> + .reserved.max = INIT_MEMBLOCK_RESERVED_REGIONS,
> .reserved.name = "reserved",
>
> #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
>
Otherwise:
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
ved on return from a runtime service.
> This allows to check for flags that are not necesarly related to
> irqflags.
>
> Signed-off-by: Julien Thierry
> Acked-by: Catalin Marinas
> Cc: Ard Biesheuvel
> Cc: linux-efi@vger.kernel.org
With the changes requested by Ard,
Acked-
Hi Jonathan,
On 05/06/2019 23:14, Jonathan Richardson wrote:
> Hi,
>
> As of the 5.0 kernel we're seeing the crash dump kernel crash when the
> gicv3-its driver calls gic_reserve_range():
[...]
> On crash dump boot, gic calls the same function, efi_mem_reserve_persistent,
> finds the entry
19 matches
Mail list logo
