On 24.07.2010 20:47, matthew green wrote: >> On 24.07.2010 09:50, Christoph Egger wrote: >> 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...) > > ah, i thought that it already used paddr_t for this. it should, imo. > > and i'd think that libkvm should be compiled with 64bit paddr_t (ie, > have the useland definition of paddr_t always be 64 bit) and be smart > enough to deal with the kernel you feed it. 32 bit sparc has to deal > with this a lot, since the page tables are considerably more different > from sparc v8/v9 than i386 vs amd64.
That would be a solution, yes. FWIW, I am making all PAE related macros and types prefixed with "pae_" (~ some kind of namespace), and alias the relevant function with them in _KERNEL when option PAE is enabled. For kvm(3), both could be used; I could extract a value from a symbol like "pae_enabled" out of a core file through kvm_nlist, then use the relevant vatop functions. -- Jean-Yves Migeon jeanyves.mig...@free.fr
