Re: [PATCH v2 08/15] x86/hyperlaunch: locate dom0 kernel with hyperlaunch

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 30 Jan 2025, Jan Beulich wrote:
> On 26.12.2024 17:57, Daniel P. Smith wrote:
> > Look for a subnode of type `multiboot,kernel` within a domain node. If 
> > found,
> > process the reg property for the MB1 module index. If the bootargs property 
> > is
> > present and there was not an MB1 string, then use the command line from the
> > device tree definition.
> 
> While multiboot is apparently the first x86-specific part (as far as Xen goes)
> to be put under domain-builder/, I wonder:
> - Wouldn't looking for "multiboot,kernel" simply yield nothing on non-x86,
>   so having the code under common/ would still be okay?

One small clarification: multiboot,kernel is actually common between
both ARM and x86. It is "module-index" which is x86-specific and would
"simply yield nothing on non-x86", as you wrote.

I'll let Dan address your point that "having the code under common/
would still be okay".


> - What's "multiboot" describing here? The origin of the module? (What other
>   origins would then be possible? How would MB1 and MB2 be distinguished?
>   What about a native xen.efi boot?) A property of the kernel (when Linux
>   doesn't use MB)?

Each device tree node has a compatible string to qualify what kind of
information the node is describing. The compatible string for device
tree nodes describing a kernel binary or a ramdisk previously loaded
into memory by a bootloader have a "multiboot," prefix. See
docs/misc/arm/device-tree/booting.txt. This is unrelated to the binary
multiboot protocol Grub uses on x86 to boot Xen.

A distinction between MB1 and MB2 is not needed in device tree, that
information is retrieved via the Grub multiboot protocol as usual. The
only thing needed here in device tree is the location of the kernel,
either by RAM address, or by Grub multiboot module index. This last
option (Grub multiboot module index) is the "module-index" property I
mentioned above.