On 21/11/2018 09:56, Jan Glauber wrote:
On Tue, Nov 20, 2018 at 06:35:42PM +0100, Ard Biesheuvel wrote:
Mapping the MEMRESERVE EFI configuration table from an early initcall
is too late: the GICv3 ITS code that creates persistent reservations
for the boot CPU's LPI tables is invoked from
On Tue, Nov 20, 2018 at 06:35:42PM +0100, Ard Biesheuvel wrote:
> Mapping the MEMRESERVE EFI configuration table from an early initcall
> is too late: the GICv3 ITS code that creates persistent reservations
> for the boot CPU's LPI tables is invoked from init_IRQ(), which runs
> much earlier than
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 late: the GICv3 ITS code that creates persistent
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 late: the GICv3 ITS code that creates persistent reservations
> > for the boot CPU's LPI tables is
Hi Ard,
On 20/11/2018 17:35, Ard Biesheuvel wrote:
> Mapping the MEMRESERVE EFI configuration table from an early initcall
> is too late: the GICv3 ITS code that creates persistent reservations
> for the boot CPU's LPI tables is invoked from init_IRQ(), which runs
> much earlier than the handling
Mapping the MEMRESERVE EFI configuration table from an early initcall
is too late: the GICv3 ITS code that creates persistent reservations
for the boot CPU's LPI tables is invoked from init_IRQ(), which runs
much earlier than the handling of the initcalls.
So instead, move the initialization
