On 14.04.2025 16:23, Alejandro Vallejo wrote:
> On Thu Apr 10, 2025 at 12:12 PM BST, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/domain-builder/fdt.c
>>> +++ b/xen/arch/x86/domain-builder/fdt.c
>>> @@ -189,6 +189,12 @@ static int __init process_domain_node(
>>> printk(" kernel: boot module %d\n", idx);
>>> bi->mods[idx].type = BOOTMOD_KERNEL;
>>> bd->kernel = &bi->mods[idx];
>>> +
>>> + /* If bootloader didn't set cmdline, see if FDT provides one.
>>> */
>>> + if ( bd->kernel->cmdline_pa &&
>>> + !((char *)__va(bd->kernel->cmdline_pa))[0] )
>>> + bd->kernel->fdt_cmdline = fdt_get_prop_offset(
>>> + fdt, node, "bootargs", &bd->kernel->cmdline_pa);
>>
>> Somewhat orthogonal question: Should there perhaps be a way for the boot
>> loader
>> provided cmdline to go at the tail of the DT provided one?
>
> That would preclude the bootloader fully overriding what's on the DT.
> One can always just copy the cmdline in the DT to the bootloader and
> adjust whatever is necessary there for testing. Adding append behaviour
> sounds more like a hindrance rather than helpful. To me at least.
Well. This is why I have been pushing for all options to also have a
"negative" form. This way you can override whatever specifically you
need to override, without re-typing the entire (perhaps long) cmdline
from DT.
Also, I didn't mean that to necessarily be the one-and-only behavior.
Jan
