From: "khandual@linux.vnet.ibm.com" <redacted>
This patch just removes one redundant entry for one extern variable
'slb_compare_rr_to_size' from the scope. This patch does not change
any functionality.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/slb.c | 1 -
1 file changed, 1 deletion(-)
From: "khandual@linux.vnet.ibm.com" <redacted>
Value of 'valid' is zero when 'esid' is zero and it does not matter
when 'esid' is non-zero. Hence the variable 'value' can be dropped
from the conditional statement. This patch does that.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/xmon/xmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -2073,6 +2073,7 @@ static void xmon_rawdump (unsigned long adrs, long ndump)staticvoiddump_one_paca(intcpu){structpaca_struct*p;+inti;if(setjmp(bus_error_jmp)!=0){printf("*** Error dumping paca for cpu 0x%x!\n",cpu);
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch defines macros for all the three bolted SLB slots. This also
renames the 'create_shadowed_slb' function as 'new_shadowed_slb'.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/slb.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
@@ -74,7 +77,7 @@ static inline void slb_shadow_clear(unsigned long slot)get_slb_shadow()->save_area[slot].esid=0;}-staticinlinevoidcreate_shadowed_slbe(unsignedlongea,intssize,+staticinlinevoidnew_shadowed_slbe(unsignedlongea,intssize,unsignedlongflags,unsignedlongslot){
@@ -103,16 +106,16 @@ static void __slb_flush_and_rebolt(void)lflags=SLB_VSID_KERNEL|linear_llp;vflags=SLB_VSID_KERNEL|vmalloc_llp;-ksp_esid_data=mk_esid_data(get_paca()->kstack,mmu_kernel_ssize,2);+ksp_esid_data=mk_esid_data(get_paca()->kstack,mmu_kernel_ssize,SLOT_KSTACK);if((ksp_esid_data&~0xfffffffUL)<=PAGE_OFFSET){ksp_esid_data&=~SLB_ESID_V;ksp_vsid_data=0;-slb_shadow_clear(2);+slb_shadow_clear(SLOT_KSTACK);}else{/* Update stack slot; others don't change */-slb_shadow_update(get_paca()->kstack,mmu_kernel_ssize,lflags,2);+slb_shadow_update(get_paca()->kstack,mmu_kernel_ssize,lflags,SLOT_KSTACK);ksp_vsid_data=-be64_to_cpu(get_slb_shadow()->save_area[2].vsid);+be64_to_cpu(get_slb_shadow()->save_area[SLOT_KSTACK].vsid);}/* We need to do this all in asm, so we're sure we don't touch
@@ -312,19 +315,19 @@ void slb_initialize(void)asmvolatile("isync":::"memory");asmvolatile("slbmte %0,%0"::"r"(0):"memory");asmvolatile("isync; slbia; isync":::"memory");-create_shadowed_slbe(PAGE_OFFSET,mmu_kernel_ssize,lflags,0);-create_shadowed_slbe(VMALLOC_START,mmu_kernel_ssize,vflags,1);+new_shadowed_slbe(PAGE_OFFSET,mmu_kernel_ssize,lflags,SLOT_KLINR);+new_shadowed_slbe(VMALLOC_START,mmu_kernel_ssize,vflags,SLOT_KVIRT);/* For the boot cpu, we're running on the stack in init_thread_union,*whichisinthefirstsegmentofthelinearmapping,andalso*get_paca()->kstackhasn'tbeeninitializedyet.*Forsecondarycpus,weneedtoboltthekernelstackslotnow.*/-slb_shadow_clear(2);+slb_shadow_clear(SLOT_KSTACK);if(raw_smp_processor_id()!=boot_cpuid&&(get_paca()->kstack&slb_esid_mask(mmu_kernel_ssize))>PAGE_OFFSET)-create_shadowed_slbe(get_paca()->kstack,-mmu_kernel_ssize,lflags,2);+new_shadowed_slbe(get_paca()->kstack,+mmu_kernel_ssize,lflags,SLOT_KSTACK);asmvolatile("isync":::"memory");}
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some documentation to 'patch_slb_encoding' function
explaining about how it clears the existing immediate value in the
given instruction and inserts a new one there.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/slb.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
@@ -94,18 +94,37 @@ static inline void new_shadowed_slbe(unsigned long ea, int ssize,:"memory");}+staticinlineunsignedlongkernel_linear_vsid_flags(void)+{+returnSLB_VSID_KERNEL|mmu_psize_defs[mmu_linear_psize].sllp;+}++staticinlineunsignedlongkernel_virtual_vsid_flags(void)+{+returnSLB_VSID_KERNEL|mmu_psize_defs[mmu_vmalloc_psize].sllp;+}++staticinlineunsignedlongkernel_io_vsid_flags(void)+{+returnSLB_VSID_KERNEL|mmu_psize_defs[mmu_io_psize].sllp;+}++#ifdef CONFIG_SPARSEMEM_VMEMMAP+staticinlineunsignedlongkernel_vmemmap_vsid_flags(void)+{+returnSLB_VSID_KERNEL|mmu_psize_defs[mmu_vmemmap_psize].sllp;+}+#endif+staticvoid__slb_flush_and_rebolt(void){/* If you change this make sure you change SLB_NUM_BOLTED*andPRKVMappropriatelytoo.*/-unsignedlonglinear_llp,vmalloc_llp,lflags,vflags;+unsignedlonglflags,vflags;unsignedlongksp_esid_data,ksp_vsid_data;-linear_llp=mmu_psize_defs[mmu_linear_psize].sllp;-vmalloc_llp=mmu_psize_defs[mmu_vmalloc_psize].sllp;-lflags=SLB_VSID_KERNEL|linear_llp;-vflags=SLB_VSID_KERNEL|vmalloc_llp;-+lflags=kernel_linear_vsid_flags();+vflags=kernel_virtual_vsid_flags();ksp_esid_data=mk_esid_data(get_paca()->kstack,mmu_kernel_ssize,SLOT_KSTACK);if((ksp_esid_data&~0xfffffffUL)<=PAGE_OFFSET){ksp_esid_data&=~SLB_ESID_V;
@@ -187,6 +206,23 @@ static inline int esids_match(unsigned long addr1, unsigned long addr2)return(GET_ESID_1T(addr1)==GET_ESID_1T(addr2));}+staticvoidslb_invalid_paca_slots(unsignedlongoffset)+{+unsignedlongslbie_data;+inti;++asmvolatile("isync":::"memory");+for(i=0;i<offset;i++){+slbie_data=(unsignedlong)get_paca()->slb_cache[i]+<<SID_SHIFT;/* EA */+slbie_data|=user_segment_size(slbie_data)+<<SLBIE_SSIZE_SHIFT;+slbie_data|=SLBIE_C;/* C set for user addresses */+asmvolatile("slbie %0"::"r"(slbie_data));+}+asmvolatile("isync":::"memory");+}+/* Flush all user entries from the segment table of the current processor. */voidswitch_slb(structtask_struct*tsk,structmm_struct*mm){
@@ -206,17 +242,7 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)offset=get_paca()->slb_cache_ptr;if(!mmu_has_feature(MMU_FTR_NO_SLBIE_B)&&offset<=SLB_CACHE_ENTRIES){-inti;-asmvolatile("isync":::"memory");-for(i=0;i<offset;i++){-slbie_data=(unsignedlong)get_paca()->slb_cache[i]-<<SID_SHIFT;/* EA */-slbie_data|=user_segment_size(slbie_data)-<<SLBIE_SSIZE_SHIFT;-slbie_data|=SLBIE_C;/* C set for user addresses */-asmvolatile("slbie %0"::"r"(slbie_data));-}-asmvolatile("isync":::"memory");+slb_invalid_paca_slots(offset);}else{__slb_flush_and_rebolt();}
@@ -256,6 +282,14 @@ static inline void patch_slb_encoding(unsigned int *insn_addr,patch_instruction(insn_addr,insn);}+/* Invalidate the entire SLB (even slot 0) & all the ERATS */+staticinlinevoidslb_invalid_all(void)+{+asmvolatile("isync":::"memory");+asmvolatile("slbmte %0,%0"::"r"(0):"memory");+asmvolatile("isync; slbia; isync":::"memory");+}+externu32slb_miss_kernel_load_linear[];externu32slb_miss_kernel_load_io[];externu32slb_compare_rr_to_size[];
From: "khandual@linux.vnet.ibm.com" <redacted>
These are essentially SLB individual slots what we are dealing with
in these functions. Usage of both 'entry' and 'slot' synonyms makes
it real confusing sometimes. This patch makes it uniform across the
file by replacing all those 'entry's with 'slot's.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/slb.c | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
@@ -55,39 +55,39 @@ static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,staticinlinevoidslb_shadow_update(unsignedlongea,intssize,unsignedlongflags,-unsignedlongentry)+unsignedlongslot){/*-*CleartheESIDfirstsotheentryisnotvalidwhileweare+*CleartheESIDfirstsotheslotisnotvalidwhileweare*updatingit.Nowritebarriersareneededhere,provided*weonlyupdatethecurrentCPU'sSLBshadowbuffer.*/-get_slb_shadow()->save_area[entry].esid=0;-get_slb_shadow()->save_area[entry].vsid=+get_slb_shadow()->save_area[slot].esid=0;+get_slb_shadow()->save_area[slot].vsid=cpu_to_be64(mk_vsid_data(ea,ssize,flags));-get_slb_shadow()->save_area[entry].esid=-cpu_to_be64(mk_esid_data(ea,ssize,entry));+get_slb_shadow()->save_area[slot].esid=+cpu_to_be64(mk_esid_data(ea,ssize,slot));}-staticinlinevoidslb_shadow_clear(unsignedlongentry)+staticinlinevoidslb_shadow_clear(unsignedlongslot){-get_slb_shadow()->save_area[entry].esid=0;+get_slb_shadow()->save_area[slot].esid=0;}staticinlinevoidcreate_shadowed_slbe(unsignedlongea,intssize,unsignedlongflags,-unsignedlongentry)+unsignedlongslot){/**UpdatingtheshadowbufferbeforewritingtheSLBensures-*wedon'tgetastaleentryhereifwegetpreemptedbyPHYP+*wedon'tgetastaleslothereifwegetpreemptedbyPHYP*betweenthesetwostatements.*/-slb_shadow_update(ea,ssize,flags,entry);+slb_shadow_update(ea,ssize,flags,slot);asmvolatile("slbmte %0,%1"::"r"(mk_vsid_data(ea,ssize,flags)),-"r"(mk_esid_data(ea,ssize,entry))+"r"(mk_esid_data(ea,ssize,slot)):"memory");}
@@ -313,13 +313,12 @@ void slb_initialize(void)asmvolatile("slbmte %0,%0"::"r"(0):"memory");asmvolatile("isync; slbia; isync":::"memory");create_shadowed_slbe(PAGE_OFFSET,mmu_kernel_ssize,lflags,0);-create_shadowed_slbe(VMALLOC_START,mmu_kernel_ssize,vflags,1);/* For the boot cpu, we're running on the stack in init_thread_union,*whichisinthefirstsegmentofthelinearmapping,andalso*get_paca()->kstackhasn'tbeeninitializedyet.-*Forsecondarycpus,weneedtoboltthekernelstackentrynow.+*Forsecondarycpus,weneedtoboltthekernelstackslotnow.*/slb_shadow_clear(2);if(raw_smp_processor_id()!=boot_cpuid&&
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-21 09:46:07
On Tue, 2015-21-07 at 06:58:40 UTC, Anshuman Khandual wrote:
From: "khandual@linux.vnet.ibm.com" <redacted>
These are essentially SLB individual slots what we are dealing with
in these functions. Usage of both 'entry' and 'slot' synonyms makes
it real confusing sometimes. This patch makes it uniform across the
file by replacing all those 'entry's with 'slot's.
No I think it would be better the other way around.
Currently we use entry in 14 places and slot in 3.
Both can be correct in some places, but not always.
For example:
- * Clear the ESID first so the entry is not valid while we are
+ * Clear the ESID first so the slot is not valid while we are
That doesn't make sense with "slot", a slot is not valid, only an entry in a
slot is valid.
Looking at the existing uses of slot they will all make sense if you change
them to entry.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-21 10:00:18
On Tue, 2015-21-07 at 06:58:45 UTC, Anshuman Khandual wrote:
From: "khandual@linux.vnet.ibm.com" <redacted>
Value of 'valid' is zero when 'esid' is zero and it does not matter
when 'esid' is non-zero.
Yes it does. It tells you whether the entry is valid?
In practice maybe you only see invalid entries that are entirely zero, and so
they get skipped anyway, but that's not guaranteed.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-21 10:08:17
On Tue, 2015-21-07 at 06:58:46 UTC, Anshuman Khandual wrote:
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some more elements to the existing PACA dump list
inside a xmon session which can be listed here.
- hmi_event_available
- dscr_default
- vmalloc_sllp
- slb_cache_ptr
- sprg_vdso
- tm_scratch
- core_idle_state_ptr
- thread_idle_state
- thread_mask
This is probably OK, except you broke the ppc64e build again.
cheers
../arch/powerpc/xmon/xmon.c: In function ���dump_one_paca���:
../arch/powerpc/xmon/xmon.c:2095:63: error: ���struct paca_struct��� has no member named ���vmalloc_sllp���
printf(" %-*s = %#-*"format"\t(0x%lx)\n", 20, #name, 18, paca->name, \
^
../arch/powerpc/xmon/xmon.c:2114:2: note: in expansion of macro ���DUMP���
DUMP(p, vmalloc_sllp, "x");
^
In file included from ../include/linux/compiler.h:56:0,
from ../include/uapi/linux/stddef.h:1,
from ../include/linux/stddef.h:4,
from ../include/uapi/linux/posix_types.h:4,
from ../include/uapi/linux/types.h:13,
from ../include/linux/types.h:5,
from ../include/uapi/linux/capability.h:16,
from ../include/linux/capability.h:15,
from ../include/linux/sched.h:15,
from ../arch/powerpc/xmon/xmon.c:14:
../include/linux/compiler-gcc.h:158:2: error: ���struct paca_struct��� has no member named ���vmalloc_sllp���
__builtin_offsetof(a, b)
^
../include/linux/stddef.h:16:32: note: in expansion of macro ���__compiler_offsetof���
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^
../arch/powerpc/xmon/xmon.c:2096:3: note: in expansion of macro ���offsetof���
offsetof(struct paca_struct, name));
^
../arch/powerpc/xmon/xmon.c:2114:2: note: in expansion of macro ���DUMP���
DUMP(p, vmalloc_sllp, "x");
^
../arch/powerpc/xmon/xmon.c:2095:63: error: ���struct paca_struct��� has no member named ���slb_cache_ptr���
printf(" %-*s = %#-*"format"\t(0x%lx)\n", 20, #name, 18, paca->name, \
^
../arch/powerpc/xmon/xmon.c:2115:2: note: in expansion of macro ���DUMP���
DUMP(p, slb_cache_ptr, "x");
^
In file included from ../include/linux/compiler.h:56:0,
from ../include/uapi/linux/stddef.h:1,
from ../include/linux/stddef.h:4,
from ../include/uapi/linux/posix_types.h:4,
from ../include/uapi/linux/types.h:13,
from ../include/linux/types.h:5,
from ../include/uapi/linux/capability.h:16,
from ../include/linux/capability.h:15,
from ../include/linux/sched.h:15,
from ../arch/powerpc/xmon/xmon.c:14:
../include/linux/compiler-gcc.h:158:2: error: ���struct paca_struct��� has no member named ���slb_cache_ptr���
__builtin_offsetof(a, b)
^
../include/linux/stddef.h:16:32: note: in expansion of macro ���__compiler_offsetof���
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^
../arch/powerpc/xmon/xmon.c:2096:3: note: in expansion of macro ���offsetof���
offsetof(struct paca_struct, name));
^
../arch/powerpc/xmon/xmon.c:2115:2: note: in expansion of macro ���DUMP���
DUMP(p, slb_cache_ptr, "x");
^
../arch/powerpc/xmon/xmon.c:2116:19: error: ���struct paca_struct��� has no member named ���slb_cache_ptr���
for (i = 0; i < p->slb_cache_ptr; i++)
^
../arch/powerpc/xmon/xmon.c:2117:50: error: ���struct paca_struct��� has no member named ���slb_cache���
printf(" slb_cache[%d]: = 0x%lx\n", i, p->slb_cache[i]);
^
make[2]: *** [arch/powerpc/xmon/xmon.o] Error 1
make[1]: *** [arch/powerpc/xmon] Error 2
@@ -223,14 +223,12 @@ static void __init check_cpu_slb_size(unsigned long node)const__be32*slb_size_ptr;slb_size_ptr=of_get_flat_dt_prop(node,"slb-size",NULL);-if(slb_size_ptr!=NULL){-mmu_slb_size=be32_to_cpup(slb_size_ptr);-return;-}-slb_size_ptr=of_get_flat_dt_prop(node,"ibm,slb-size",NULL);-if(slb_size_ptr!=NULL){-mmu_slb_size=be32_to_cpup(slb_size_ptr);+if(!slb_size_ptr){+slb_size_ptr=of_get_flat_dt_prop(node,"ibm,slb-size",NULL);+if(!slb_size_ptr)+return;}+mmu_slb_size=be32_to_cpup(slb_size_ptr);}
It's still ugly. Why not go the whole way:
p = of_get_flat_dt_prop(node, "slb-size", NULL) ? :
of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
if (p)
mmu_slb_size = be32_to_cpup(p);
And while you're at it, rename the function, it doesn't check anything. It
initialises mmu_slb_size, so call it init_mmu_slb_size()?
cheers
On Tue, 2015-21-07 at 06:58:40 UTC, Anshuman Khandual wrote:
quoted
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
These are essentially SLB individual slots what we are dealing with
in these functions. Usage of both 'entry' and 'slot' synonyms makes
it real confusing sometimes. This patch makes it uniform across the
file by replacing all those 'entry's with 'slot's.
No I think it would be better the other way around.
Currently we use entry in 14 places and slot in 3.
Both can be correct in some places, but not always.
For example:
quoted
quoted
- * Clear the ESID first so the entry is not valid while we are
+ * Clear the ESID first so the slot is not valid while we are
That doesn't make sense with "slot", a slot is not valid, only an entry in a
slot is valid.
Looking at the existing uses of slot they will all make sense if you change
them to entry.
@@ -223,14 +223,12 @@ static void __init check_cpu_slb_size(unsigned long node)const__be32*slb_size_ptr;slb_size_ptr=of_get_flat_dt_prop(node,"slb-size",NULL);-if(slb_size_ptr!=NULL){-mmu_slb_size=be32_to_cpup(slb_size_ptr);-return;-}-slb_size_ptr=of_get_flat_dt_prop(node,"ibm,slb-size",NULL);-if(slb_size_ptr!=NULL){-mmu_slb_size=be32_to_cpup(slb_size_ptr);+if(!slb_size_ptr){+slb_size_ptr=of_get_flat_dt_prop(node,"ibm,slb-size",NULL);+if(!slb_size_ptr)+return;}+mmu_slb_size=be32_to_cpup(slb_size_ptr);}
It's still ugly. Why not go the whole way:
p = of_get_flat_dt_prop(node, "slb-size", NULL) ? :
of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
if (p)
mmu_slb_size = be32_to_cpup(p);
Yeah this is better.
And while you're at it, rename the function, it doesn't check anything. It
initialises mmu_slb_size, so call it init_mmu_slb_size()?
On Tue, 2015-21-07 at 06:58:45 UTC, Anshuman Khandual wrote:
quoted
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
Value of 'valid' is zero when 'esid' is zero and it does not matter
when 'esid' is non-zero.
Yes it does. It tells you whether the entry is valid?
Yeah but it does not change the outcome of the if condition check
here. Non-zero esid will make the condition test pass irrespective
of the value of 'valid'. Yes, valid will be checked inside the code
block to print details, the point was value of valid does not make
any difference to the 'if' condition check in the first place.
Unless I am getting tricked here some how :)
In practice maybe you only see invalid entries that are entirely zero, and so
they get skipped anyway, but that's not guaranteed.
On Tue, 2015-21-07 at 06:58:46 UTC, Anshuman Khandual wrote:
quoted
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some more elements to the existing PACA dump list
inside a xmon session which can be listed here.
- hmi_event_available
- dscr_default
- vmalloc_sllp
- slb_cache_ptr
- sprg_vdso
- tm_scratch
- core_idle_state_ptr
- thread_idle_state
- thread_mask
This is probably OK, except you broke the ppc64e build again.
Will fix it up while sending this as a patch series. Thanks for
the quick review of the series.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-22 04:52:35
On Tue, 2015-07-21 at 17:15 +0530, Anshuman Khandual wrote:
On 07/21/2015 03:30 PM, Michael Ellerman wrote:
quoted
On Tue, 2015-21-07 at 06:58:45 UTC, Anshuman Khandual wrote:
quoted
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
Value of 'valid' is zero when 'esid' is zero and it does not matter
when 'esid' is non-zero.
Yes it does. It tells you whether the entry is valid?
Yeah but it does not change the outcome of the if condition check
here. Non-zero esid will make the condition test pass irrespective
of the value of 'valid'. Yes, valid will be checked inside the code
block to print details, the point was value of valid does not make
any difference to the 'if' condition check in the first place.
Unless I am getting tricked here some how :)
No you're right, I was confused by the bitwise or.
Please make it: if (esid || vsid)
And drop valid entirely, just do the check in the if condition.
And fix the change log:
Hence the variable 'value'
^
valid
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-22 05:51:04
On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
quoted hunk
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some documentation to 'patch_slb_encoding' function
explaining about how it clears the existing immediate value in the
given instruction and inserts a new one there.
How about:
/*
* This function patches either an li or a cmpldi instruction with
* a new immediate value. This relies on the fact that both li
* (which is actually ori) and cmpldi both take a 16-bit immediate
* value, and it is situated in the same location in the instruction,
* ie. bits 0-15.
* To patch the value we read the existing instruction, clear the
* immediate value, and or in our new value, then write the instruction
* back.
*/
cheers
From: Gabriel Paubert <hidden> Date: 2015-07-22 06:39:21
On Wed, Jul 22, 2015 at 03:51:03PM +1000, Michael Ellerman wrote:
On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some documentation to 'patch_slb_encoding' function
explaining about how it clears the existing immediate value in the
given instruction and inserts a new one there.
How about:
/*
* This function patches either an li or a cmpldi instruction with
* a new immediate value. This relies on the fact that both li
* (which is actually ori) and cmpldi both take a 16-bit immediate
Hmm, li is actually encoded as addi with r0 as source register...
* value, and it is situated in the same location in the instruction,
* ie. bits 0-15.
In PPC documentation, it's rather bits 16-31 (big endian bit order).
Or say lower half which is endian agnostic.
Cheers,
Gabriel
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-22 09:01:24
On Wed, 2015-07-22 at 07:57 +0200, Gabriel Paubert wrote:
On Wed, Jul 22, 2015 at 03:51:03PM +1000, Michael Ellerman wrote:
quoted
On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
quoted
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds some documentation to 'patch_slb_encoding' function
explaining about how it clears the existing immediate value in the
given instruction and inserts a new one there.
How about:
/*
* This function patches either an li or a cmpldi instruction with
* a new immediate value. This relies on the fact that both li
* (which is actually ori) and cmpldi both take a 16-bit immediate
Hmm, li is actually encoded as addi with r0 as source register...
Correct.
quoted
* value, and it is situated in the same location in the instruction,
* ie. bits 0-15.
In PPC documentation, it's rather bits 16-31 (big endian bit order).
Or say lower half which is endian agnostic.
Yeah, but who reads the PPC documentation ;)
In the kernel we almost always use the sane bit numbering, so I'd use that, but
maybe "low 16-bits" will avoid confusion.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-22 09:19:51
On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch adds the following helper functions to improve modularization
and readability of the code.
(1) slb_invalid_all: Invalidates entire SLB
This reads badly. Although invalid can be a verb, the meaning of invalid as a
verb is not correct here. You want "invalidate".
(2) slb_invalid_paca_slots: Invalidate SLB entries present in PACA
Ditto.
But, I think that's the wrong abstraction.
We should just have one routine, slb_invalidate(), which deals with all the
mess. ie. checking the MMU_FTR and the offset etc. So basically the whole
if/else.
(3) kernel_linear_vsid_flags: VSID flags for kernel linear mapping
(4) kernel_virtual_vsid_flags: VSID flags for kernel virtual mapping
mmu_vmalloc_vsid_flags() ?
etc.
ie. have the function names match the mmu psize names. I don't think we need
"kernel" in the name, I think that's implied.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2015-07-22 09:32:23
On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
quoted hunk
From: "khandual@linux.vnet.ibm.com" <redacted>
This patch defines macros for all the three bolted SLB slots. This also
renames the 'create_shadowed_slb' function as 'new_shadowed_slb'.
Signed-off-by: Anshuman Khandual <redacted>
---
arch/powerpc/mm/slb.c | 27 +++++++++++++++------------
1 file changed, 15 insertions(+), 12 deletions(-)
KSTACK_SLOT
And the comment is wrong, it's not 0xf00.., that's the vmemmap.
I know we're inconsistent about FOO_SLOT vs SLOT_FOO at times, but I think in
this case it reads better as FOO_SLOT.
Actually even better, make it an enum?
cheers
On Wed, Jul 22, 2015 at 03:51:03PM +1000, Michael Ellerman wrote:
How about:
/*
* This function patches either an li or a cmpldi instruction with
* a new immediate value. This relies on the fact that both li
* (which is actually ori) and cmpldi both take a 16-bit immediate
* value, and it is situated in the same location in the instruction,
* ie. bits 0-15.
* To patch the value we read the existing instruction, clear the
* immediate value, and or in our new value, then write the instruction
* back.
*/
As Gabriel says, li is addi. It takes a 16-bit sign-extended immediate,
while cmpldi takes a 16-bit zero-extended immediate. This function
doesn't deal with that difference, it probably should (I didn't check if
the callers take care; there should be an assertion somewhere).
Segher