Multiboot: First argument in cmdline or module_string is ignored by module when booting Xen

[digitalrane]

Whilst testing Limine for booting the Xen hypervisor on BIOS systems, I found that the first parameter/option in cmdline or module_string seems to be ignored in the booted Xen kernel, and also in the Linux kernel which is booted by Xen and passed as the first multiboot module.

This was tested using the multiboot1 module, as the multiboot2 module does not seem to be able to boot Xen multiboot kernels. I've also opened #482 to track that, but it's mostly just background as to why I'm only testing aginst multiboot1 currently.

I am able to work around this behaviour by simply adding -- to the start of both the cmdline: line, which is passed to Xen as arguments, and also to the module_string: line which is passed to the kernel booted by Xen as the dom0 domain. With -- at the start of the string, both Xen and the booted Linux kernel in the dom0 domain have their full list of arguments available.

Looking at the messages printed by Limine during boot, it does appear that the configuration is being parsed correctly, as the whole string is visible (including the -- if present) in the logs, but the first value is not present in the booted kernel or subsequent modules.

Example configuration entry follows:

//Generation 65 with Xen 4.19.1
comment: Xen 4.19.1 NixOS Warbler 25.05.git.54e03cf469f9M (Linux 6.12.20), built on 2025-03-29 04:30:45
protocol: multiboot
path: boot():/limine/xen/65/boot-xen-4.19.1#27bc442eda318f203fc2886ed336ac1a7ceb1e2a6cab2316ded6a308637f71c9446b6dd5ef3a351f1dcae6aca1e7731ccd5dc9f65ee969676a652ace50c684ae
cmdline: -- iommu=off cpufreq=xen,verbose cpuidle dom0_mem=4096M dom0_max_vcpus=4 guest_loglvl=all loglvl=all loglvl=all guest_loglvl=allmodule_path: boot():/limine/kernels/0wcyc5l289wlvb1zwjm0kwqczl9f2kb4-linux-6.12.20-bzImage#d17bac41190b9826c774284b774ef805f2f58f1849be43aff3e299305ae5858e12c33373a21c7e3295669ce0f0cedfb458e10f178be31841516f1354d3f5cb44
module_string: -- init=/nix/store/249rxcvgal64s0js00z8s8zcwrk43gcv-nixos-system-nixos-25.05.git.54e03cf469f9M/init nomodeset console=hvc0 root=fstab loglevel=4
module_path: boot():/limine/kernels/fz90w7w8ajv6xrgv5rhrrm6qki66bla5-initrd-linux-6.12.20-initrd#7c1a41bf61d383a2c0a323a291857811d50d39cb8940b7f40c3a561c91a276546beb422d112a6b0f783d43cb2c9fdb3907dc21994c37a60b40d835c7592d21a6

This is a non-reproducer example, so if the -- is removed from the cmdline and module_string lines above, it should reproduce the behaviour described by this issue.

[mintsuki]

Like for #482 , please provide the file you're trying to boot, if you can. Thanks.

[digitalrane]

@mintsuki No problem. I've uploaded the Linux bzImage and Xen multiboot (should be multiboot1 and 2 headers in place) images to https://junkyard.systems/limine-nixos-test-binaries.tar.xz - these were built on NixOS and I've seen this behavior across both of those files. It does not seem specific to a certain payload, and I don't see it with other boot protocols, just multiboot1. Potentially the same would be true of multiboot2 but per #482 I wasn't able to test that out.

[mintsuki]

I looked into this, but I am quite convinced that this is an issue (if at all) with Xen code, not with us. Saying this mainly because it happens on both multiboot1 and multiboot2 and those 2 protocols have quite different code, making the chance of a bug being shared by both quite low.

Additionally, we do not do any parsing of the command line string passed to multiboot kernels; nothing that should cause the first portion of the string, before the first space, to be chopped off.

I'll leave the issue open anyways as a way to keep track of research into this.

[mintsuki]

Ah, also forgot to mention that additionally all other multiboot kernels tested do not exhibit this issue.