Re: [PATCH v2 05/21] xen/arm: extend device tree based multiboot protocol

[Stefano Stabellini <sstabellini@kernel.org>]

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 <stefanos@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