From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: mapping of memory below 16Mb Date: Fri, 25 Jan 2008 07:51:02 +0000 Message-ID: <4799A2F5.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 24.01.08 17:22 >>> >On 24/1/08 15:26, "Keir Fraser" wrote: > >>> One point I got a little surprised about while doing the 1Gb page = support: >>> The 1:1 mapping of the low 16 Mb (and most significantly the first Mb) >>> created at boot time is being retained permanently. Shouldn't Xen be >>> following the E820 map also for this memory range (by either not >>> mapping non-RAM at all or at best mapping them UC/WP)? >>=20 >> Below 1MB is a special case, and 1MB-16MB we're dodging BIOS tables, = not >> actual hardware. At least this is the case for all system I know about. = If >> there are exceptions which we care about, then we can try harder. = Otherwise >> that code is quite complicated enough as it is. > >Actually this isn't hard to fix now I think about it. Also we should be >mapping the range 0-4MB or 0-2MB with 4kB mappings anyway, to avoid >conflicting with memory access constraints specified by the fixed MTRRs. >Every modern BIOS sets the fixed MTRRs with a mixture of memory types, = and >if we map that range with a superpage we either get undefined behaviour = or >at best (e.g., Intel CPUs) the processor will implicitly shatter the >superpage mapping so that we get 4kB-mapping levels of performance = anyway. > >This has a side 'benefit' that the range 0-1GB cannot be mapped with a = 1GB >superpage mapping, and that simplifies your patch a bit (since we will = never >need to free the statically-allocated first few l2e ident mapping pages). Actually - no, it would guarantee only the first of them would never be freed. The others, as long as head.S puts them into l3_identmap unconditionally, will still be subject to eventual freeing. Jan