On 13 Oct 00 at 13:42, Timur Tabi wrote:
> ** Reply to message from Ingo Molnar <mingo@elte.hu> on Fri, 13 Oct 2000
> 20:44:19 +0200 (CEST)
> > processes are not limited to a single segment, eg. Wine uses nonstandard
> > segments. But as i said, using multiple segments does not let you out of
> > 32 bits of virtual memory.
>
> Sure it does, just like segments let 16-bit apps access more than 64KB of
> memory. If you have two selectors, each one can point to a different physical
> base address, and IIRC, the size of the physical address base can be 36 bits.
> That gives you 16 physically contiguous 4GB memory blocks.
Sure it does not. Selectors point to linear addresses, before passing them
through pagetables. You have 32+14 bits of virtual address (32 = offset,
14 = valid bits in selector), which are translated, together with
offset, to 32 bit linear address. This 32bit linear address is passed
through pagetables to 36 bit physical address. So it must go through
32bit linear address, and there is no easy way to overcome this limit.
You can either (1) forget about simple pointers and dereferencing pointers,
and go through realmode windows way - you must GlobalLock() memory area,
and you'll get pointer. Then you GlobalUnlock()... And you can lock
at most 2GB (maybe 3GB if you'll thought really good algorithm) of such
data... Or (2) make complete segment non present, and on pagefault
unmap all pages belonging to some selector + invalidate selector, and
map something else in. You must create at least four such areas,
as you must have mapped at least CS, SS, ES and one of DS/FS/GS to
successfully execute MOVSB... So each area should be < 256MB.
Are you really sure that it is worth of effort? Also do not forget
that 'sizeof(void*) > sizeof(long)' in such environment, so tons of
code broke... And someone must translate pointers from 48bits to 32
for kernel use...
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:25 EST