Re: [PATCH] x86/mm/init: respect memblock reserved regions when destroying mappings

[Yinghai Lu <yinghai@kernel.org>]

On Mon, Feb 7, 2011 at 8:56 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> On 02/07/2011 07:12 PM, Yinghai Lu wrote:
>> On 02/07/2011 01:56 PM, Jeremy Fitzhardinge wrote:
>>> On 02/07/2011 11:00 AM, Yinghai Lu wrote:
>>>> On 02/07/2011 10:58 AM, Stefano Stabellini wrote:
>>>>> On Mon, 7 Feb 2011, Yinghai Lu wrote:
>>>>>> On 02/07/2011 08:50 AM, Stefano Stabellini wrote:
>>>>>>> On Sun, 6 Feb 2011, Yinghai Lu wrote:
>>>>>>>> On 02/05/2011 11:30 PM, H. Peter Anvin wrote:
>>>>>>>>> On 02/05/2011 11:02 PM, Yinghai Lu wrote:
>>>>>>>>>> why not just move calling cleanup_highmap down?
>>>>>>>>>>
>>>>>>>>>> something like attached patch.
>>>>>>>>> This patch looks very clean and looks on the surface of it like it is
>>>>>>>>> removing some ugly ad hoc code, but (as always) it needs a description
>>>>>>>>> about the problem it solves and why it is correct.
>>>>>>>> Sure.
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy and xen guys, can you please check if it works well with xen ?
>>>>>>>>
>>>>>>> Actually this patch makes things worse on xen, because before
>>>>>>> cleanup_highmap() wasn't called at all on xen (on purpose) and now it
>>>>>>> is, fully destroying all the mappings we have at _end.
>>>>>>>
>>>>>>> Can we add a check on memblock reserved regions in cleanup_highmap()?
>>>>>>> Otherwise could we avoid calling cleanup_highmap() at all on xen?
>>>>>> why DO xen need over-mapped kernel initial mapping?
>>>>>>
>>>>>> what is in that range after _end to 512M?
>>>>> The mfn list that is the list of machine frame numbers assigned to this
>>>>> domain; it is used across the kernel to convert pfns into mfns.
>>>>> It passed to us at that address by the domain builder.
>>>> is it possible for you to pass physical address, and then map it in kernel?
>>> That is possible in principle, but very difficult in practice.
>>>
>>> What's wrong with honouring reserved memory ranges under all circumstances?
>> why punishing native path with those checking?
>
> Why is it punishing anyone to expect memory reservations to be observed?
>
>> please check if
>>
>> +      * max_pfn_mapped is set to KERNEL_IMAGE_SIZE >> PAGE_SHIFT in
>> +      *   head64.c::x86_start_kernel(), aka native path
>> +      */
>> +     if (max_pfn_mapped != (KERNEL_IMAGE_SIZE >> PAGE_SHIFT))
>> +             return;
>>
>> could be used to skip clear highmap for xen path?
>
> Seems pretty ad-hoc.
>

then what is size for mfn-list after _end...

could be copied or move to BRK.

Yinghai