RE: [RFC PATCH 0/2] Introduce reserved Xenheap

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi Julien,

Thanks very much for your time reading the series and your feedback. Please
find the inline reply below.

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Saturday, February 26, 2022 4:09 AM
> To: Henry Wang <Henry.Wang@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> sstabellini@xxxxxxxxxx
> Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>; Wei Chen
> <Wei.Chen@xxxxxxx>; Penny Zheng <Penny.Zheng@xxxxxxx>
> Subject: Re: [RFC PATCH 0/2] Introduce reserved Xenheap
> 
> Hi Henry,
> 
> On 24/02/2022 01:30, Henry Wang wrote:
> > The reserved Xenheap, or statically configured Xenheap, refers to parts
> > of RAM reserved in the beginning for Xenheap. Like the static memory
> > allocation, such reserved Xenheap regions are reserved by configuration
> > in the device tree using physical address ranges.
> 
> In Xen, we have the concept of domheap and xenheap. For Arm64 and x86
> they would be the same. But for Arm32, they would be different: xenheap
> is always mapped whereas domheap is separate.
> 
> Skimming through the series, I think you want to use the region for both
> domheap and xenheap. Is that correct?

Yes I think that would be correct, for Arm32, instead of using the full
`ram_pages` as the initial value of `heap_pages`, we want to use the
region specified in the device tree. But we are confused if this is the
correct (or preferred) way for Arm32, so in this series we only
implemented the reserved heap for Arm64.

Could you please share your opinion on this? Thanks!

> 
> Furthemore, now that we are introducing more static region, it will get
> easier to overlap the regions by mistakes. I think we want to have some
> logic in Xen (or outside) to ensure that none of them overlaps. Do you
> have any plan for that?

Totally agree with this idea, but before we actually implement the code,
we would like to firstly share our thoughts on this: One option could be to
add data structures to notes down these static memory regions when the
device tree is parsed, and then we can check if they are overlapped. Over
the long term (and this long term option is currently not in our plan),
maybe we can add something in the Xen toolstack for this usage?

Also, I am wondering if the overlapping check logic should be introduced
in this series. WDYT?

> 
> >
> > This feature is useful to run Xen on Arm MPU systems, where only a
> > finite number of memory protection regions are available. The limited
> > number of protection regions places requirement on planning the use of
> > MPU protection regions and one or more MPU protection regions needs to
> > be reserved only for Xenheap.
> >
> > Therefore, this patch series is sent as RFC for comments from the
> > community. The first patch introduces the reserved Xenheap and the
> > device tree processing code. The second patch adds the implementation of
> > the reserved Xenheap pages handling in boot and heap allocator on Arm64.
> >
> > Henry Wang (2):
> >    docs, xen/arm: Introduce reserved Xenheap memory
> >    xen/arm: Handle reserved Xenheap pages in boot/heap allocator
> >
> >   docs/misc/arm/device-tree/booting.txt | 43 ++++++++++++++++++++++
> >   xen/arch/arm/bootfdt.c                | 52 +++++++++++++++++++++------
> >   xen/arch/arm/include/asm/setup.h      |  3 ++
> >   xen/arch/arm/setup.c                  | 52 +++++++++++++++++++--------
> >   4 files changed, 125 insertions(+), 25 deletions(-)
> >
> 
> --
> Julien Grall

Kind regards,

Henry