WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] mapping of memory below 16Mb

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 24.01.08 17:22 >>>
>On 24/1/08 15:26, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> 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)?
>> 
>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel