Re: Using emap for i386/amd64 early during boot

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 21.06.2010 00:39, Mindaugas Rasiukevicius wrote:
> Jean-Yves Migeon<jeanyves.migeon%free.fr@localhost>  wrote:
> > > I know that a lot of legacy code uses the preprocessor the way that you
> > > have in i386_cpu_switch_pmap(), but I don't think that the preprocessor
> > > should be used in that way any longer.  In my experience, code that uses
> > > the preprocessor heavily is harder to read and to change and to test.
> > > Why don't you let config(1) and ld(1) do the work that the preprocessor
> > > does?  For example:
> >   >[snip]
> >
> > I like that. Will do. Thanks!
>
> Agree with David's point, but it should not be done at function level.
> Rather higher level interface abstraction.  In uvmplock branch, I have
> already split some x86 pmap bits into pmap_tlb.c and xen_pmap.c modules.
> More interfaces can be abstracted in respect to e.g. Xen.

I just took a look: to avoid ugly #ifdef's, we have to handle 4 
different scenarios for pmap switching:

- i386 native, amd64 native, and i386 Xen (no-PAE) case, which all share 
the same piece of code (use of lcr3)

- i386 PAE, not Xen: iterate through L3 entries, without Xen address 
physical => machine address translation

- i386 PAE, Xen: same as above, but use P2M translations

- amd64 Xen, where pmap code has some quirks to circumvent amd64 
limitations regarding paravirtualization.

I can split Xen and non-Xen case, but we will still have to distinguish 
i386 and amd64 case, as well as PAE/!PAE (within i386). Either we deal 
with it at function level and let config(1) handle that, or cpp(1). 
Choice is limited here :/

For your branch:
* xen/x86/xen_pmap.c will contain the code for i386 (PAE & !PAE), amd64, 
only for Xen

* x86/x86/pmap.c will contain native i386 (PAE & !PAE), and amd64.

Is pmap.c expected to be split in two files too (pmap.c and x86_pmap.c?) 
I noticed that in your pmap.c, some functions (already found in 
xen_pmap.c) are "#ifndef XEN" out, to avoid conflict I suppose.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost