Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754664Ab2HWUWg (ORCPT ); Thu, 23 Aug 2012 16:22:36 -0400 Received: from mail-vb0-f46.google.com ([209.85.212.46]:36418 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581Ab2HWUWc (ORCPT ); Thu, 23 Aug 2012 16:22:32 -0400 Date: Thu, 23 Aug 2012 16:12:25 -0400 From: Konrad Rzeszutek Wilk To: "H. Peter Anvin" Cc: Jacob Shin , X86-ML , LKML , Yinghai Lu , Andreas Herrmann , Tejun Heo , Borislav Petkov , Dave Young , Chao Wang , Vivek Goyal Subject: Re: [PATCH 3/4] x86: Only direct map addresses that are marked as E820_RAM Message-ID: <20120823201224.GA24203@phenom.dumpdata.com> References: <1344983957-4996-1-git-send-email-jacob.shin@amd.com> <1344983957-4996-4-git-send-email-jacob.shin@amd.com> <50356BA9.5030906@zytor.com> <20120823145043.GA4671@jshin-Toonie> <50364E9E.6020104@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50364E9E.6020104@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2502 Lines: 56 On Thu, Aug 23, 2012 at 08:39:10AM -0700, H. Peter Anvin wrote: > 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!) Can you rope me in on that? Was that added ooh years ago ? > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/