On Mon, 9 Jul 2018, Julien Grall wrote: > Hi, > > On 07/07/18 00:12, Stefano Stabellini wrote: > > Extend the existing device tree based multiboot protocol to include > > information regarding multiple domains to boot. > > > > Signed-off-by: Stefano Stabellini <stefa...@xilinx.com> > > > > --- > > Changes in v2: > > - lower case kernel > > - rename mem to memory > > - mandate cpus and memory > > - replace domU-kernel with kernel and domU-ramdisk with ramdisk > > - rename xen,domU with xen,domain > > - add info about dom0 > > - switch memory and cpus to integers > > - remove defaults > > - add vpl011 > > --- > > docs/misc/arm/device-tree/booting.txt | 108 > > ++++++++++++++++++++++++++++++++++ > > 1 file changed, 108 insertions(+) > > > > diff --git a/docs/misc/arm/device-tree/booting.txt > > b/docs/misc/arm/device-tree/booting.txt > > index ce2d0dc..5c3b8da 100644 > > --- a/docs/misc/arm/device-tree/booting.txt > > +++ b/docs/misc/arm/device-tree/booting.txt > > @@ -119,3 +119,111 @@ 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 Multiple Domains 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 > > +(optional) need to be specified for each guest. > > + > > +For each domain to be created there needs to be one node under /chosen > > +with the following properties: > > + > > +- compatible > > + > > + For domUs: "xen,domain" > > + For dom0: "xen,domain", "xen,initial-domain" > > Looking briefly at the code, I don't see any support of "xen,initial-domain". > Did I miss anything? > > But, it is a bit strange to put that in compatible. Shouldn't this be a > property?
I haven't implemened this in this series yet. Let's add "xen,initial-domain" to the spec together with the implementation in one of the follow-up series. > > + > > +- memory > > + > > + An integer specifying the amount of megabytes of RAM to allocate to > > + the guest. > > I would define this a KB. With Dom0less it would be easy to spawn a guest with > less than a MB of memory. What matter is the amount of memory should be > page-aligned. I think it would be good to allow users to specify the memory in KB, you are right that we might be able to have <1MB guests. At the same time, it is a pain to have to deal with KBs when allocating multi GBs guests. Any suggestion on how to make this more user friendly? Maybe we could find a way to support multiple units, for instance we could support memory_mb (for MBs) and memory_kb (for KBs). Or we could just suck it up and use KBs only. I mean, if we have to support one unit only, it should probably be KBs. I wonder if it makes sense to rename memory to memory_<unit> in any case for clarity. > > + > > +- cpus > > + > > + An integer specifying the number of vcpus to allocate to the guest. > > + > > +- vpl011 > > + > > + An integer to enable/disable a virtual pl011 for the guest to use. > > The interrupt is a bit confusing here. What value will enable? What value will > disable? > > I think you can just make an empty property. OK _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel