Re: CVS commit: src/sys/arch

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

On 24.07.2010 09:50, Christoph Egger wrote:
>> XXX Mixing PAE and !PAE modules may lead to unwanted/unexpected results. This
>> cannot be solved easily, and needs lots of thinking before being declared
>> safe (paddr_t/bus_addr_t size handling, PD/PT macros abstractions).
> 
> How about making paddr_t always 64bit? That makes it much easier to deal
> with in libkvm.

Not necessarily, the kvm(3) API manipulates PA as u_long (see
_kvm_kvatop in kvm_i386.c). Changing the paddr_t will need a
modification of this API too, and basically, all ports will have to move
to uint64_t PA (or put casts everywhere...)

> paddr_t being always 64bit wide also allows to switch PAE on and off at
> runtime like Solaris does.

And *off* at runtime?

That's one requirement, however you would have tons of extra work to
make pmap "dynamically" switch from !PAE to PAE, due to paddr_t, pd/pt,
bus_addr_t modifications. That would need a modular pmap, and load that
module very early.

IMHO, "if it ever gets done", we should add Xen to the loop (and fix
that module path issue). So that we would have only one kernel for DOM0,
GENERIC and GENERIC PAE.

Besides, I suspect that turning paddr_t to uint64_t will add overhead,
even if the upper 32 bits are always 0 in GENERIC.

> Pleaes fix the amd64 build error reported on current-users@.
> The build error is related to rump.

Investigating. rumptest just finished for i386 and amd64, and no error
whatsoever. Guess I'll have to dig further...

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