tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Using emap for i386/amd64 early during boot

On Wed, 23 Jun 2010 01:10:09 +0100, Mindaugas Rasiukevicius
<> wrote:
> Jean-Yves Migeon <> wrote:
>> Is pmap.c expected to be split in two files too (pmap.c and
>> I noticed that in your pmap.c, some functions (already found in 
>> xen_pmap.c) are "#ifndef XEN" out, to avoid conflict I suppose.
> Not into pmap.c and x86_pmap.c - it is already x86. :) But yes, some
> routines which tend to differ between i386 and amd64 might be abstracted
> into
> separate {i386,amd64}_pmap.c modules.  However, I am thinking of higher
> level
> abstractions first, for example - splitting page table management code
> pmap_pt.c and making it a clearer interface.

And what would that be?

IMHO, i386 and amd64 PD/PT code is already pretty much abstracted, thanks
to PTP_LEVELS and all the pl_ index magic :) Within pmap, there is a
minimal set of #ifdef's for i386 and amd64 in the native case. The rest is
mostly due to Xen.

One exception is for PAE, but I can't think of any solution so far -- the
code remains very close to 386 native, only pmap context switch is

AFAICS, with x86 "native":
  - i386 PAE
  - i386 native and amd64 native 

PT management looks similar, some #ifdef PAE needed due to the "masked" L3
layer. Affected code is CPU trampoline (cpu_hatch, MP tramp, the per-CPU L3
allocation), pmap_load (heh).I tried to keep the #ifdef PAE at a minimum,
thanks to the PDP_SIZE loop (which is unrolled by compiler when PDP_SIZE is

With Xen:
  - i386 non-PAE
  - i386 PAE
  - amd64 native

3 cases to handle, due to the amd64 quirks I mentioned earlier, which
makes rather hard to bring i386 and amd64 cases similar within Xen (except
by adding more indirection layers, but I fear we will duplicate code parts
everywhere -- cargo cult programming?)

I'd prefer to rely on your wisdom and experience there :)


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index