On 27.09.2019 14:54, hong...@amazon.com wrote:
> On 26/09/2019 15:26, Wei Liu wrote:
>> On Thu, Sep 26, 2019 at 10:46:34AM +0100, hong...@amazon.com wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1367,7 +1367,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>
>>> if ( map_e < end )
>>> {
>>> - map_pages_to_xen((unsigned long)__va(map_e),
>>> maddr_to_mfn(map_e),
>>> + map_pages_to_xen((unsigned long)__va(map_e), INVALID_MFN,
>>> PFN_DOWN(end - map_e), PAGE_HYPERVISOR);
>>
>> Why don't you just remove the calls to map_pages_to_xen?
>>
>
> My intention is to pre-populate the range so that we don't have to do so
> later
> when there are xenheap allocations. But of course if there is superpage
> merging
> or shattering, page tables will be removed or allocated anyway. I will remove
> the calls in the next revision.
Pre-populate? There's some conceptional question then: When the
direct map is gone, are you mapping Xen heap pages into the place
they'd have lived at in the direct map? I'm not convinced that's
what we want. In fact I'm not convinced we'd want to retain the
distinction between Xen heap and domain heap then any further -
there's no reason anymore at that point (afaict).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
