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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 13/07/18 23:41, Stefano Stabellini wrote:
> On Mon, 9 Jul 2018, Julien Grall wrote:
> > 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@xxxxxxxxxx>
> > >
> > > ---
> > > 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.
It is not very difficult, You just use your wcalc (or any calculator) 
and do a shift 30.
> 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).
That's ugly because you know have to describe clearly what they are for 
or otherwise someone may think it would be fine to describe your 1.5GB 
guest as:
memory_gb = 1
memory_mb = 512

If you want to make user-friendly then provide macros to generate the 
device-tree. This is already used for describe GIC controller in Linux.
> 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.
I would prefer to keep "memory" and encourage users to read the 
associated documentation.
Cheers,

--
Julien Grall

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