lkml.org 
[lkml]   [2012]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] x86: Only direct map addresses that are marked as E820_RAM
On 08/23/2012 07:50 AM, Jacob Shin wrote:
>>
>> I have one concern with this, which is that it leaves in place mapping
>> below the initial max_pfn_mapped. Although that neatly resolves the
>> legacy area (0-1 MiB) issues, it really isn't right above the 1 MiB
>> point. Any way I could get you to seek out and unmap any such ranges?
>> We have already seen some Dell machines which put memory holes in low
>> RAM, and perhaps there are still some machines out there with an I/O
>> hole at 15 MiB.
>
> So I believe in V2 of the patchset this was done, however, Dave Young
> from redhat reported that it broke their KVM guest with a user supplied
> memory map that looked like this:
>
>>> [ 0.000000] e820: user-defined physical RAM map:
>>> [ 0.000000] user: [mem 0x0000000000010000-0x000000000009dbff] usable
>>> [ 0.000000] user: [mem 0x0000000024000000-0x0000000033f6bfff] usable
>
> And looking into that scenario, the early boot code seems to allocates
> space for fixmap right under initial max_pfn_mapped, which is no longer
> direct mapped with my patch, and that seems to cause problems for later
> APIC code that initializes APIC base address into the fixmap area.
>
> So I guess to address your concern, we need to go back to V2 and try to
> resolve the fixmap problem with user supplied memory map that reserves
> memory below initial max_pfn_mapped ?
>

Okay... I think I need to grok that a bit better. For memory
allocations, we probably should just use brk allocations, for virtual
space allocations it is called the fixmap for a reason (even though the
Xen people managed to break that on 32 bits, sigh!)

I guess I need to go back and look at David's bug report...

-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2012-08-23 19:41    [W:0.090 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site