Re: Mapping non-prefetchable memory

Stephen C. Tweedie (sct@dcs.ed.ac.uk)
Sun, 23 Mar 1997 15:31:03 GMT


Hi,

On Sun, 23 Mar 1997 00:13:29 -0800, Rakesh Dubey <rdubey@cisco.com>
said:

> Also, just to confirm this, in 2.0.x world kmalloc() returns
> contiguous, same phy as virt, locked, non-cached memory -- right?

Nearly but not quite. kmalloc() returns contiguous, locked, *cached*
memory, whose virtual address appears to be the same as its physical,
but isn't (!).

In the ix86 processors, kmalloc() returns addresses in the kernel's
own primary address space, which maps one-to-one onto physical
addresses. This kernel space actually lives at virtual address
0xc0000000, however, not 0x00000000 which is where physical memory
starts.

Fortunately, the kernel's segment registers (CS, DS and SS) are all
set up with a base of 0xc0000000, so the necessary offset to turn
physical into virtual addresses is already added for you by the
segment registers whenever you are in kernel mode. Hence, physical
and virtual addresses appear to be the same. (Incidentally, this is
why you have to use a different segment register, FS, to access
user-mode data in the 2.0 and earlier kernels.)

> I know this will change in 2.1.X but I am debugging my driver now and
> don't want to move to 2.1.x at this time.

OK, but it's really no big deal to do. Just #include <asm/io.h>, and
you can use the functions phys_to_virt() and virt_to_phys() to perform
the necessary translations. The 2.1 ix86 kernel does NOT perform the
segment magic done by 2.0, so you do need to take account of the
translation yourself. On 2.0, these functions are just macros which
do nothing, so there's no harm in adding them anyway.

Making sure that you always do the translations between the address
spaces has another advantage --- it makes your device driver portable
to other versions of Linux which may not share the same view of
physical memory. For example, with a little care, the Alpha port can
run most PCI device drivers with no source code change from the ix86
version.

Cheers,
Stephen.