Re: CVS commit: src/sys/arch

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

On Tue, 17 Aug 2010 14:26:53 +0000, Andrew Doran <ad%NetBSD.org@localhost> 
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.migeon%free.fr@localhost