query related to create_slbe

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Apr 16 17:23:57 EST 2005

On Fri, 2005-04-15 at 18:12 +0530, R Sharada wrote:
> Hello,
> 	I was trying to understand the slb code and the creation of slb entries
> in the Linux kernel, and came up with a few queries in the process. The code
> I am referring to is 2.6.12-rc2-mm3 code-base.
> 1) in slb.c
> within slb_initialize:
> 	 create_slbe(KERNELBASE, get_kernel_vsid(KERNELBASE), flags, 0);
>         create_slbe(VMALLOCBASE, get_kernel_vsid(KERNELBASE),
>                     SLB_VSID_KERNEL, 1);
>         /* We don't bolt the stack for the time being - we're in boot,
>          * so the stack is in the bolted segment.  By the time it goes
>          * elsewhere, we'll call _switch() which will bolt in the new
>          * one. */
>         asm volatile("isync":::"memory");
> #endif
>         get_paca()->stab_rr = SLB_NUM_BOLTED;
> => we seem to be creatig slb entries for kernelbase and vmallocbase (2 entries)
> however in mmu.h
> #define SLB_NUM_BOLTED          3
> => seems to indicate we are bolting 3 entries. Perhaps I am missing something?  

The third one is the current kernel stack. As the comment in the code
explains, we do not need to bolt it at this point, since we are booting,
thus using init_mm's stack which is in the bolted kernel segment
already. The next time we switch processes, the new stack will be

> 2) Relating to the same code above, create_slbe seems to take the vsid as an
> argument, but never seems to be using it, as seen in the code below:
> static inline void create_slbe(unsigned long ea, unsigned long vsid,
>                                unsigned long flags, unsigned long entry)
> {
>         asm volatile("slbmte  %0,%1" :
>                      : "r" (mk_vsid_data(ea, flags)),
>                        "r" (mk_esid_data(ea, entry))
>                      : "memory" );
> }
> => again, am I missing something?

No, I suppose this is historical crap, and we end up calling
get_kernel_vsid() twice, good catch ! Nothing really bad here though,
I'm adding to my TODO list and will submit a patch one of these days if
nobody beats me to it.


More information about the Linuxppc64-dev mailing list