[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.