From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Physical Memory Addresses
Date:	Sun, 22 Sep 1996 11:45:06 CDT
Organization:	Rice University, Houston, Texas
Lines:	29
Message-ID:	<32456d12.sandmann@clio.rice.edu>
References:	<9609180832 DOT AA26846 AT leopard DOT proteon DOT com>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> BTW, if anyone can tell me how to read the CPU's CR3 register when you
> are not a protection level 0, I would love you here from you! I'm
> pretty sure it is impossible without hacking the DPMI server to give
> you the value through a new (non-DPMI) interface call.

You are right that it's not possible in the general sense.
There is a back door approach to get this informtion under CWSDPMI, so
you do this under the ring 3 version.  In general:
  sgdt  can get you the linear base of the gdt table
  str   can get you the current task register
  Looking directly in the gdt table you can compute the base address of
   the current task structure
  Offset 1c into that structure will get you your CR3 value.
If you do this carefully with some checking, you can detect non-CWSDPMI
hosts and avoid doing bad things.

Using this technique you then have direct access to the page tables, with
all the advantages (and hazards).  Using the nearptr or farptr routines,
you can then read or write the page tables directly, as long as you make
the "operating system" bits consistent with what CWSDPMI expects (see it's
documentation in paging.h).

Using this technique, you can then read page tables to set up the DMA 
buffers in the 1Mb to 16Mb range (you may need to modify the tables since
anything over 4K may not be contigous - careful touching of pages in order
should page them in contigous).

You can also see how much of the stack you have used, and lots of other
fun things if you are handy with page tables.

- Raw text -