On Fri, 27 Mar 2026 03:06:41 -0700 Breno Leitao <[email protected]> wrote:
> Hi Masami, > > On Wed, Mar 25, 2026 at 11:22:04PM +0900, Masami Hiramatsu wrote: > > On Wed, 25 Mar 2026 03:05:38 -0700 > > Breno Leitao <[email protected]> wrote: > > > > +/* > > > + * 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. > > > 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) <[email protected]>
