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

["Wei Chen (Arm Technology China)" <Wei.Chen@xxxxxxx>]

Hi Julien,

> -----Original Message-----
> From: Julien Grall <julien.grall@xxxxxxx>
> Sent: 2018年9月7日 22:45
> To: Wei Chen (Arm Technology China) <Wei.Chen@xxxxxxx>; Simon Kuenzer
> <simon.kuenzer@xxxxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Kaly Xin (Arm Technology China) <Kaly.Xin@xxxxxxx>
> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv5 15/46] plat/include: Define
> address offsets of boot stack and pagetable
>
> 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.
>

Why I can't assume that? I will design the link script and write the boot
code, I can tell kernel image how to use the RAM. Anything I had missed?

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

I remember we had discussed it in previous version about implementing an
"init section". We may do it in later patches, but not now.

> [...]
>
> >>>>> +
> >>>>> +/*
> >>>>> + * 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
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel