Messages in this thread | | | Date | Thu, 23 Aug 2012 08:39:10 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [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.
| |