[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and heap allocator





On 02/09/2022 04:30, Henry Wang wrote:
Hi Julien,

Hi Henry,

-----Original Message-----
From: Julien Grall <julien@xxxxxxx>
This code is now becoming quite confusing to understanding. This loop is
meant to map the xenheap. If I follow your documentation, it would
mean
that only the reserved region should be mapped.

Yes I think this is the same question that I raised in the scissors line of the
commit message of this patch.

Sorry I didn't notice the comment after the scissors line. This is the
same question :)

What I intend to do is still mapping the whole
RAM because of the xenheap_* variables that you mentioned in...


More confusingly, xenheap_* variables will cover the full RAM.

...here. But only adding the reserved region to the boot allocator so the
reserved region can become the heap later on. I am wondering if we
have a more clear way to do that, any suggestions?

I think your code is correct. It only needs some renaming of the
existing variable (maybe to directmap_*?) to make clear the area is used
to access the RAM easily.

Thanks for the clarification. I checked the code and found the xenheap_*
variables are:
xenheap_virt_start, xenheap_virt_end, xenheap_mfn_start,
xenheap_mfn_end, xenheap_base_pdx.

For clarification, do we need to change all of them to directmap_*?

Good question.


A pure renaming should be easy (and I guess also safe), but maybe I am
overthinking because arm32 also uses xenheap_virt_end, xenheap_mfn_start
and xenheap_mfn_end. These variables refer to the real xenheap, I am not
sure renaming these would reduce the readability for arm32.

So on arm32, only the xenheap is direct mapped today. So I think it would be fine to switch the name to "directmap_*". For extra clarify we could add an alias for arm32 between "xenheap_*" and "directmap_*".

Cheers,

--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.