On Tue, 17 Aug 2010 14:26:53 +0000, Andrew Doran <a...@netbsd.org> wrote: > Hi, > > Why are any types other than in the pmap different between PAE and !PAE? > > When this was originally proposed I asked for stuff like paddr_t to be 64 > bits no matter what the kernel compile settings where. > > Thanks.
<short_explanation> I need more time! </short_explanation> <long_explanation> Let's do this /gradually/. There are already regressions with PAE that needs fixing before moving further, especially "bugs" that people reported to me I cannot reproduce with my hosts (a.out breakage with Xen PAE + NX, and invalid TLB entries that only happens 'randomly' with some AMD 64 Athlon CPUs). That, and also: - rmind@ branch work on uvm/pmap. Such a change will interfere with his work. - the issue is wider, bus_addr_t will move to "all 64 bits" too (performance impact?) - p{d,t}_entry_t vs paddr_t size mix up in pmap, which is bad in the !PAE case (32 vs 64 bits). Breaking i386 pmap will not be particularly good for my life expectancy. - I want to merge xensuspend before entering another bug hunting session :) One at a time is enough :) - this is orthogonal to the kvm(3) issue: having 64 bits in-kernel paddr_t will not automagically solve the "all PAs are unsigned long" assumption of kvm(3). </long_explanation> -- Jean-Yves Migeon jeanyves.mig...@free.fr