Re: [Minios-devel] [UNIKRAFT PATCHv5 15/46] plat/include: Define address offsets of boot stack and pagetable

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 09/07/2018 10:36 AM, Wei Chen (Arm Technology China) wrote:
> > -----Original Message-----
> > From: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>
> > Sent: 2018年9月7日 17:29
> > To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; minios-
> > devel@xxxxxxxxxxxxxxxxxxxx
> > Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> > Subject: Re: [Minios-devel] [UNIKRAFT PATCHv5 15/46] plat/include: Define
> > address offsets of boot stack and pagetable
> >
> > On 07.09.2018 07:14, Wei Chen (Arm Technology China) wrote:
> > > Hi Simon,
> > >
> > > > -----Original Message-----
> > > > From: Simon Kuenzer <simon.kuenzer@xxxxxxxxx>
> > > > Sent: 2018年9月6日 22:53
> > > > To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; minios-
> > > > devel@xxxxxxxxxxxxxxxxxxxx
> > > > Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> > > > Subject: Re: [Minios-devel] [UNIKRAFT PATCHv5 15/46] plat/include: Define
> > > > address offsets of boot stack and pagetable
> > > >
> > > > Hey Wei,
> > > >
> > > > These defines for the memory layout are specific for KVM for now, right?
> > > > Wouldn't it then make sense to place this files to plat/kvm/include?
> > > > Or do you know if this is going to be the same for Xen?
> > > I want to use the same memory layout for KVM and Xen. I know that current
> > > Code for Xen platform is ported from mini-os. But once, when code for
> > > Arm/KVM becomes stable, I want reuse most of the code for these two
> > > platforms.
> > Okay, sounds reasonable. Could you add this as one sentence in the
> > commit message to eplain why you decided to place this to common/?
> Ok, I will add similar comment in the commit message.
I don't think this memory layout is going to work well with Xen because 
you can't assume there are free RAM after the kernel image.
It would be best if you make sure the boot stack and pagetable are 
contained in BSS but towards the end. You can then free them once you 
are done with it. This has also the advantage to avoid hardcoding address.
[...]

> > > > > +
> > > > > +/*
> > > > > + * Each entry in L0_TABLE can link to a L1_TABLE which supports 512GiB
> > > > > + * memory mapping. One 4K page can provide 512 entries. In this case,
> > > > > + * one page for L0_TABLE is enough for current stage.
> > > > > + */
> > > > > +#define L0_TABLE_OFFSET 0
> > > > > +#define L0_TABLE_SIZE   PAGE_SIZE
> > > > > +
> > > > > +/*
> > > > > + * Each entry in L1_TABLE can map to a 1GiB memory or link to a
> > > > > + * L2_TABLE which supports 1GiB memory mapping. One 4K page can provide
> > > > > + * 512 entries. We need at least 2 pages to support 1TB memory space
> > > > > + * for platforms like KVM QEMU virtual machine.
> > > > > + */
> > > > > +#define L1_TABLE_OFFSET (L0_TABLE_OFFSET + L0_TABLE_SIZE)
> > > > > +#define L1_TABLE_SIZE   (PAGE_SIZE * 2) ~
> > > > > +
> > > > > +/*
> > > > > + * Each entry in L2_TABLE can map to a 2MiB block memory or link to a
> > > > > + * L3_TABLE which supports 2MiB memory mapping. We need a L3_TABLE to
> > > > > + * cover image area for us to manager different sections attributes.
> > > > > + * So, we need one page for L2_TABLE to provide 511 enties for 2MiB
> > > > > + * block mapping and 1 entry for L3_TABLE link.
> > > > > + */
> > > > > +#define L2_TABLE_OFFSET (L1_TABLE_OFFSET + L1_TABLE_SIZE)
> > > > > +#define L2_TABLE_SIZE   PAGE_SIZE
> > > > > +
> > > > > +/*
> > > > > + * As Unikraft image's size is very tiny, from tens to hundreds kilo
> > > > > + * bytes. So one page for L3_TABLE is enough for us to manage section
> > > > > + * attributes of image.
How come? Someone might want to use QEMU (or any big software) with 
Unikraft. The resulting image size would be in tens MB.
Cheers,

--
Julien Grall

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