[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 wouldmeanthat 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |