|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|