Re: Calculating kernel logical address ..

[Daniel Phillips <phillips@arcor.de>]

On Sunday 08 September 2002 02:01, David S. Miller wrote:
>    From: Daniel Phillips <phillips@arcor.de>
>    Date: Sat, 7 Sep 2002 03:44:53 +0200
>    
>    It looks good to me.  Note that somebody has added some new voodoo in 2.5
>    so that page table pages can be in highmem, with the result that the above
>    code won't work in 2.5, whether or not highmem is configured.
> 
> The example given won't work for kernel text/data addresses on a few
> platforms (sparc64 is one).  And in fact on MIPS the KSEG0 pages lack
> any page tables.
> 
> There are only three things one can portably obtain a physical address
> of:
> 
> 1) A user address, for a known MM
> 
> 2) a kmalloc/get_free_page kernel page
> 
> 3) A vmalloc page

Actually, he was trying to obtain a kernel virtual address, which
presents its own difficulties, particularly with respect to highmem.

> For anything else you're in non-portablt land, including and
> in partiular:
> 
> 1) kernel stack addresses

Could you elaborate on what bad things happen here?

> 2) addresses within the main kernel image text/data/bss

Yep.  MIPS's KSEG0 (a stupid design if there ever was one) and i386 large
kernel image pages are just two examples of wrinkles that would need to
be handled.  The general principle is: mappings in the kernel's virtual
address space are not maintained by the faulting mechanism, they are
maintained 'by hand'; and the cross-platform N-level page tree is defined
only for addresses that can fault.

Where the page tree does define a mapping to physical memory, obviously
only a physical address may be obtained that way, and due to highmem,
this address may not be mapped into the kernel's virtual address range,
in which case a further kmapping step has to be performed to obtain a
kernel-usable address, subject to bizarre rules that tend to change on
a weekly basis.

Somebody needs to write a book about this ;-)

-- 
Daniel