Re: [PATCH 3/4] x86: Only direct map addresses that are marked asE820_RAM
From: H. Peter Anvin
Date: Thu Aug 23 2012 - 11:39:20 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/