Touching the initrd before paging_init

[Mark Rutland]

Hi,

On Sun, Dec 13, 2015 at 03:47:12AM -0500, Jon Masters wrote:
> Hi Folks,
> 
> Just a few notes that might be useful to someone else.
> 
> I mentioned before that we'll want to see ACPI_INITRD_TABLE_OVERRIDE
> support on arm64 in due course for use during bringup of new systems. It
> is commonly used on x86 to provide handy updated ACPI tables via a
> prepended initrd cpio that is attached to the regular initrd image,
> which is infinitely better than respinning firmware each time you want
> to provide updated tables (yes yes, we all know the "devicetree"
> directive in GRUB does this with DT and that's great and wonderful). I
> know that someone is working on it, but I had a need for an interim
> solution over the weekend for some hardware I am bringing up here.

Which table(s) are you trying to override?

It might be possible to have an EFI application prior to the kernel which
override the relevant table, or you may be able to override the tables in the
EFI stub. From the PoV of Linux proper, things would then be the same as a
normal boot -- nothing special to be done.

If you're able to do this in a separate application prior to the stub (or even
prior to the main bootloader), that same override should work for any OS.

> The problem is that there's no mapping for the pages containing the
> ramdisk data prior to paging_init.Can we not move paging_init earlier?

Why can't we move paging_init earlier? Which information do we need prior to
paging_init?

The only thing I can think of are the SLIT and SRAT. Are you trying to override
those?

> x86 does a bit of hoop jumping (and I think they have certain assumptions
> about linear mapping too) and splits the initrd setup into a couple of
> different phases, which we may well need to do also if we want to be able to
> call something like:
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_BLK_DEV_INITRD)
>         acpi_initrd_override((void *)initrd_start, initrd_end -
> initrd_start);
> #endif
> 
> prior to acpi_boot_table_init in arch/arm64/kernel/setup.c. That routine
> will correctly map memory for data it copies out of the cpio, but it
> assumes that the initrd is already mapped. For the very nasty hack I
> want over the weekend, I added some extra fixmaps and then do an
> early_memremap on the physical address of first page of the initrd (the
> cpio is tiny, and is always prepended and this is very nasty). Viz:
> 
> [    0.000000] JCM: using fixmap for first page of ramdisk...
> [    0.000000] JCM: first physical page of ramdisk: [mem REDACTED]
> [    0.000000] JCM: first virtual page of ramdisk: [mem REDACTED]
> [    0.000000] XXXX ACPI table found in initrd
> [kernel/firmware/acpi/xxxx.aml][0xxxx]
> [    0.000000] XXXX ACPI table found in initrd
> [kernel/firmware/acpi/xxxx.aml][0xxx]
> [    0.000000] XXXX ACPI table found in initrd
> [kernel/firmware/acpi/xxxx.aml][0xxxx]
> 
> So maybe I'll get what I want working, but a head's up to whoever from
> Linaro ends up looking into the broader implementation that I think
> you'll need to rework initrd mapping as part of that. Unless of course
> I'm missing something. Which is more than possible.

If we really need to map the initrd this early, one option would be to make it
possible to perform arbitrarily large memremaps early on, following the
approach I posted for the linear mapping [1]. That would require some more
invasive rework, but we'd be able to reuse the logic for other things we want
to map early on.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/392292.html