How CPU(x86) resolve kernel address

How CPU(x86) resolve kernel address

[Sanket Rathi]

I read all about the memory management in linux. all thing are clear to me
like there is 3GB space for user procee and 1GB for kernel and thats why
kernel address always greater then 0xC0000000. But one thing is not clear
that is for kernel address there is no page table, actually there is no
need because this is one to one mapping to physical memory but who resolve
kernel address to actual physical address how CPU(X86) perform this task
because when we do DMA we have to give actual physical address by
virt_to_phys() so what is the mechanism by which CPU translate kernel
address into physical address ( Somewhere i heard that CPU ignore some of
the upper bits of address if so then how much bits and why).

Thanks in advance 

--- Sanket Rathi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: How CPU(x86) resolve kernel address

[Joseph A Knapka]

Sanket Rathi wrote:

> I read all about the memory management in linux. all thing are clear to me
> like there is 3GB space for user procee and 1GB for kernel and thats why
> kernel address always greater then 0xC0000000. But one thing is not clear
> that is for kernel address there is no page table,


Yes there is. Look for swapper_pg_dir. It maps physical address
N to virtual address PAGE_OFFSET+N.

> actually there is no
> need because this is one to one mapping to physical memory but who resolve
> kernel address to actual physical address how CPU(X86) perform this task
> because when we do DMA we have to give actual physical address by
> virt_to_phys() so what is the mechanism by which CPU translate kernel
> address into physical address ( Somewhere i heard that CPU ignore some of
> the upper bits of address if so then how much bits and why).


I don't think so. Kernel and user addresses all pass through
the virtual mapping mechanism. virt_to_phys() just subtracts
PAGE_OFFSET from the kernel virtual address to arrive at the
physical address

Cheers,


-- Joe
   Using open-source software: free.
   Pissing Bill Gates off: priceless.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: How CPU(x86) resolve kernel address

[Ravi]

> I read all about the memory management in linux. all thing are clear
> to me like there is 3GB space for user procee and 1GB for kernel and 
> thats why kernel address always greater then 0xC0000000. But one 
> thing is not clear that is for kernel address there is no page table,


 Page table for kernel addresses does exist. Take a look at how
'swapper_pg_dir' is set up in pagetable_init() (arch/i386/mm/init.c).
init_mm->pgd points to swapper_pg_dir, so kernel threads and the idle
context use this page table.
 Most of the time, the kernel executes in the context of a user
process. Each process' page table contains mappings for kernel virtual
addresses also. 

> actually there is no need because this is one to one mapping to 
> physical memory 

 Once paging is turned on, there is always a need for page table. The
one-to-one mapping is a feature of Linux (and maybe any other OS), not
required by the processor. Also, there is no one-to-one mapping in case
of kernel addresses obtained by interfaces like vmalloc(), kmap() and
ioremap().

> what is the mechanism by which CPU translate kernel address into 
> physical address 

  The CPU does not treat kernel addresses differently in case of
virtual-physical translation. 

> ( Somewhere i heard that CPU ignore
> some of the upper bits of address if so then how much bits and why).
 
  12 least significant bits of the Page directory entry and page table
entry are used for flags. Since the least page size supported on i386
is 4k, the last 12 bits always correspond to the offset within a page.
So they are not needed for address translation. [The flags are defined
in include/asm-i386/pgtable.h].

Hope this helps,
Ravi.

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: How CPU(x86) resolve kernel address

[Eric W. Biederman]

Sanket Rathi <sanket.rathi@cdac.ernet.in> writes:

> I read all about the memory management in linux. all thing are clear to me
> like there is 3GB space for user procee and 1GB for kernel and thats why
> kernel address always greater then 0xC0000000. But one thing is not clear
> that is for kernel address there is no page table, actually there is no
> need because this is one to one mapping to physical memory but who resolve
> kernel address to actual physical address how CPU(X86) perform this task
> because when we do DMA we have to give actual physical address by
> virt_to_phys() so what is the mechanism by which CPU translate kernel
> address into physical address ( Somewhere i heard that CPU ignore some of
> the upper bits of address if so then how much bits and why).

Ouch virt_to_phys ouch! ouch! ouch!  Don't do that.

At the very least use virt_to_bus.  And almost certainly use
pci_alloc_consistent.  On x86 the devices and the cpu happen to see
the same addresses for memory.  On other architecture this just
doesn't work.

read:
Documentation/DMA-mapping.txt
Documentation/IO-mapping.txt

As for the page tables yes the kernel uses them.  But because it has
a simple mapping from virtual to physical address it can do a lot of
optimizations that don't normally work.  Like using 4MB pages.

Note that in the vmalloc region we use normal sized pages, and that
vmalloc actually has a smaller address space than normal kernel
memory, and there is a minor performance hit for using it, as the
normal optimization do not apply.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/