Re: i386 PAE support (Patches)

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

On 01/04/10 22:30, Manuel Bouyer wrote:
> > Yes, it is the use of ptoa() on integer values (frame number, for
> > example), which could be higher than 1M with PAE.
> >
> > The problem is encountered in pmap, and some drivers, with ptoa() used
> > on variables like physmem, with a potential overflow when physical
> > memory is greater than 4GiB.
>
> Yes, I understand this. but I don't understand why it's not a problem
> with Xen (my guess is that in reality, it doesn't overflow in
> that much places).

Seems to be the case, yes.

To date, I have seen the problem (only from source code reading while 
porting Jeremy's patch to current) on some stat counters in UVM (number 
of free/inactive/... pages), x86 (non Xen) pmap and the agp + cardbus 
code. There may be some in ddb and libkvm too.

> My problem with the way ptoa is fixed here is that it doesn't fix
> the overflow: there are several places where the result is stored
> in a 32bit integer (see the 2 functions above for example).
> Here it's not ptoa() which needs to be fixed, but the code needs to
> detect the overflow and use a sensible value in this case.

(the casts could also hide compile-time type checks)

IMHO (as some have suggested earlier), there is no real need to add 64 
bits overhead for non-PAE; I'd suggest to use paddr_t/psize_t types 
instead of hardcoding uintxx_t values. And use ctob/btoc instead of 
ptoa/atop in these cases... ?

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