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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 16 Jul 2018, Julien Grall wrote:
> 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

Yes, that would be bad


> 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.

I'll keep memory and only use kb for now. If somebody comes up with a
good idea we can switch to that in follow versions.

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