Re: [Xen-devel] [PATCH RFC 03/15] xen/arm: extend device tree based multiboot protocol

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 13/06/18 23:15, Stefano Stabellini wrote:
> Extend the existing device tree based multiboot protocol to include
> information regarding other domUs to boot.
>
> Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> ---
>   docs/misc/arm/device-tree/booting.txt | 102 ++++++++++++++++++++++++++++++++++
>   1 file changed, 102 insertions(+)
>
> diff --git a/docs/misc/arm/device-tree/booting.txt 
> b/docs/misc/arm/device-tree/booting.txt
> index ce2d0dc..95255e5 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -119,3 +119,105 @@ For those you would hardcode the Xen commandline in the 
> DTB under
>   line by writing bootargs (as for native Linux).
>   A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
>   for Dom0 and bootargs for native Linux.
> +
> +
> +Creating DomUs directly from Xen
> +================================
> +
> +It is possible to have Xen create other domains, in addition to dom0,
> +out of the information provided via device tree. A Kernel and initrd
NIT: s/Kernel/kernel/

> +(optional) need to be specified for each guest.
> +
> +For each DomU to be created there needs to be one node under /chosen
> +with the following properties:
I think it would be better to make this domain agnostic. I.e allow Dom0 
to be created the same way but still supporting the current bindings.
We could differentiate Dom0 from the other with a property 
"xen,initial-domain". Note that I am not asking to add this property in 
this series. This is more a forward looking of the use of this binding.
> +
> +- compatible
> +
> +    "xen,domU"
If we follow my suggestion, this would be renamed "xen,domain".

> +
> +- mem (optional)
I would prefer the full name "memory".

> +
> +    A string specifying the amount of RAM to allocate to the guest. If
> +    not specified it defaults to "64M". The format of the string is the same
> +    as the one for the mem= parameter in xl config files.
I don't much like default values because they are pretty arbitrary. This 
also does not match the default value for Dom0. Why don't you mandate 
the property?
I would also prefer if the size is specified in the same way number are 
described in Device-Tree. I.e using cells. You could impose 2 cells for 
the size here.
> +
> +- cpus (optional)
> +
> +    A string specifying the number of vcpus to allocate to the guest. If
> +    not specified it defaults to "1".
Same remarks as for "mem".

> +
> +- #address-cells and #size-cells
> +
> +    Both #address-cells and #size-cells need to be specified because
> +    both sub-nodes (described shortly) have reg properties.
> +
> +Under the "xen,domU" compatible node, one or more sub-nodes are present
> +for the DomU kernel and ramdisk.
> +
> +The kernel sub-node has the following properties:
> +
> +- compatible
> +
> +    "multiboot,domU-kernel"
I don't think we need to specify a new compatible here. We could re-use 
"multiboot,kernel" here because the parent node will contain "xen,domU".
> +
> +- reg
> +
> +    Specifies the physical address of the kernel in RAM and its
> +    length.
> +
> +- bootargs (optional)
> +
> +    Command line parameters for the guest kernel.
> +
> +The ramdisk sub-node has the following properties:
> +
> +- compatible
> +
> +    "multiboot,domU-ramdisk"
Same here, we could re-use "multiboot,ramdisk".

> +
> +- reg
> +
> +    Specifies the physical address of the ramdisk in RAM and its
> +    length.
We should mention somewhere that this should be described in the /chosen 
node of the device-tree.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel