On Fri, 27 Mar 2026 03:06:41 -0700
Breno Leitao [off-list ref] wrote:
Hi Masami,
On Wed, Mar 25, 2026 at 11:22:04PM +0900, Masami Hiramatsu wrote:
quoted
On Wed, 25 Mar 2026 03:05:38 -0700
Breno Leitao [off-list ref] wrote:
quoted
quoted
+/*
+ * bootconfig_apply_early_params - dispatch kernel.* keys from the embedded
+ * bootconfig as early_param() calls.
+ *
+ * early_param() handlers must run before most of the kernel initialises
+ * (e.g. before the GIC driver reads irqchip.gicv3_pseudo_nmi). A bootconfig
+ * attached to the initrd arrives too late for this because the initrd is not
+ * mapped yet when early params are processed. The embedded bootconfig lives
+ * in the kernel image itself (.init.data), so it is always reachable.
+ *
+ * This function is called from setup_boot_config() which runs in
+ * start_kernel() before parse_early_param(), making the timing correct.
+ */
+static void __init bootconfig_apply_early_params(void)
[sashiko comment]
| Does this run early enough for architectural parameters?
| While setup_boot_config() runs before parse_early_param() in start_kernel(),
| it runs after setup_arch(). setup_boot_config() relies on xbc_init() which
| uses the memblock allocator, requiring setup_arch() to have already
| initialized it.
| However, the kernel expects many early parameters (like mem=, earlycon,
| noapic, and iommu) to be parsed during setup_arch() via the architecture's
| call to parse_early_param(). Since setup_arch() completes before
| setup_boot_config() runs, will these architectural early parameters be
| silently ignored because the decisions they influence were already
| finalized?
This is the major reason that I did not support early parameter
in bootconfig. Some archs initialize kernel_cmdline in setup_arch()
and setup early parameters in it.
Would it be feasible to document which parameters are architecture-specific
and must be processed during setup_arch()?
Yeah, at least we can mark what is not available in bootconfig.
Or, maybe we can export this function to setup_arch() for each
architecture.
Anyway, some cmdline options are not possible to be passed via
bootconfig. IIRC, for example, the initrd image address is
passed via cmdline (via devicetree) on arm64 from bootloader.
We could potentially introduce a third parameter category alongside the
existing early_param() and __setup():
* early_param()
* __setup()
* early_arch_param() (New)
This would allow bootconfig to support __setup() and early_param() while
explicitly excluding early_arch_param() from bootconfig processing.
Yeah, that maybe possible.
This would move break down the early parameters in those that can be
easily handled.
quoted
To fix this, we need to change setup_arch() for each architecture so
that it calls this bootconfig_apply_early_params().
Could we instead integrate this into parse_early_param() itself? That
approach would avoid the need to modify each architecture individually.
Ah, indeed.
Thanks!
Thanks for looking at it,
--breno
--
Masami Hiramatsu (Google) [off-list ref]