Re: [RFC PATCH] Describe chosen modules for hypervisor booting

["Alex Bennée" <alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:

> On Fri, Apr 21, 2023 at 11:40 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> When booting something like a hypervisor there is need to communicate
>> to it how the first guest will be loaded. Typically the firmware or
>> boot loader will put the kernel and ramdisk in memory and pass the
>> information to the hypervisors boot code. This mechanism currently
>> works with Xen on the Arm platform and would be equally applicable to
>> other such hypervisors.
>
> This is probably something to discuss on the boot-architecture list.
>
>>
>> However this specification doesn't address the needs of a dom0less
>> system (where there is no "root" guest to launch the others) so is
>> currently very much an RFC.
>
> In the end, whatever you want to add will need a DT schema. Really,
> just a schema would be fine. Much of /chosen is not in the spec.

Where are these schema's stored?

I'm agnostic about where we eventually document this behaviour as long
as we can come up with a canonical documentation of it somewhere.
Otherwise I worry we will end up with numerous approaches all slightly
different in their behaviour.

>
>> Signed-off-by: Alex Bennée <alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Julien Grall <julien-LM2mM/qkH7s@public.gmane.org>
>> Cc: Stefano Stabellini <sstabellini-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Carl van Schaik <cvanscha-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
>> ---
>>  source/chapter3-devicenodes.rst | 55 +++++++++++++++++++++++++++++++++
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst
>> index 958257e..3c021a4 100644
>> --- a/source/chapter3-devicenodes.rst
>> +++ b/source/chapter3-devicenodes.rst
>> @@ -488,6 +488,61 @@ For compatibility, a client program might want to support
>>  *linux,stdout-path* if a *stdout-path* property is not present. The meaning
>>  and use of the two properties is identical.
>>
>> +``chosen`` modules
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +In a multi-stage boot, for example booting a hypervisor directly, the
>> +firmware may need to describe where the booting stage can find the
>> +next bit of software. These are described with one or more ``module``
>> +nodes which describe where in memory the module can be found and how
>> +to boot it. The ``module`` nodes should be filtered out from the DT
>> +passed to the next stage.
>
> I think 'image' would be a bit clearer than 'module'.
>
>> +
>> +.. tabularcolumns:: | p{4cm} p{0.75cm} p{4cm} p{6.5cm} |
>> +.. table:: ``/chosen/module`` Node Properties
>> +
>> +   ======================= ===== ===================== ===============================================
>> +   Property Name           Usage Value Type            Definition
>> +   ======================= ===== ===================== ===============================================
>> +   ``bootargs``            O     ``<string>``          A string that specifies the boot arguments for
>> +                                                       the client program. The value could
>> +                                                       potentially be a null string if no boot
>> +                                                       arguments are required.
>> +   ``compatible``          OR    ``<string>``          Describes the module, may contain the following
>> +                                                       strings:
>> +
>> +                                                       - ``multiboot,kernel``: This indicates the
>> +                                                         module is a multiboot compatible
>> +                                                         kernel image
>
> What does "multiboot compatible" mean?
>
>> +
>> +                                                       - ``multiboot,ramdisk``:
>> +                                                         This indicates the module is a ramdisk
>> +                                                         image. Kernels confirming to the
>> +                                                         multiboot spec will expect to be
>> +                                                         pointed to the ramdisk as part of
>> +                                                         the boot information
>
> Why don't the existing initrd properties work?
>
>> +   Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
>> +   ===================================================================================================
>> +
>> +**Example**
>> +
>> +.. code-block:: dts
>> +
>> +    chosen {
>> +            bootargs = "dom0_mem=128M loglvl=all guest_loglvl=all";
>> +            stdout-path = "/pl011@9000000";
>> +
>> +            module@0x47000000 {
>> +                    bootargs = "console=hvc0";
>> +                    compatible = "multiboot,module\0multiboot,kernel";
>> +                    reg = <0x00 0x47000000 0x00 0xe47a00>;
>> +            };
>> +    };
>> +
>> +In this example the root bootargs are passed to the first stage and
>> +configure the hypervisor with the module being a kernel image that the
>> +hypervisor will boot with specific arguments for the guests kernel.
>> +
>>  ``/cpus`` Node Properties
>>  -------------------------
>>
>> --
>> 2.39.2
>>


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro