LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] powerpc/64s/hash: Use POWER9 SLBIA IH=3 variant in switch_mm
From: Nicholas Piggin @ 2018-08-11  8:18 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Nicholas Piggin

POWER9 introduces SLBIA IH=3, which invalidates all SLB entries
and associated lookaside information that have a class value of
1, which Linux assigns to user addresses. This matches what
switch_slb wants, and allows a simple fast implementation that
avoids the slb_cache complexity.

Process context switching rate is improved about 2.2% for a
small process (that hits the slb cache).

Signed-of-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/powerpc/mm/slb.c     | 56 +++++++++++++++++++++++++--------------
 arch/powerpc/mm/slb_low.S |  9 ++++---
 arch/powerpc/xmon/xmon.c  | 11 +++++---
 3 files changed, 49 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 0b095fa54049..8f8e3df5cfb0 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -238,29 +238,42 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
 	 * which would update the slb_cache/slb_cache_ptr fields in the PACA.
 	 */
 	hard_irq_disable();
-	offset = get_paca()->slb_cache_ptr;
-	if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
-	    offset <= SLB_CACHE_ENTRIES) {
-		int i;
-		asm volatile("isync" : : : "memory");
-		for (i = 0; i < offset; i++) {
-			slbie_data = (unsigned long)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 */
-			asm volatile("slbie %0" : : "r" (slbie_data));
-		}
-		asm volatile("isync" : : : "memory");
+
+	if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+		/*
+		 * SLBIA IH=3 invalidates all Class=1 SLBEs and thir
+		 * associated lookaside structures, which matches what
+		 * switch_slb wants. So ARCH_300 does not use the slb
+		 * cache.
+		 */
+		asm volatile("isync ; " PPC_SLBIA(3)" ; isync");
 	} else {
-		__slb_flush_and_rebolt();
-	}
+		offset = get_paca()->slb_cache_ptr;
+		if (!mmu_has_feature(MMU_FTR_NO_SLBIE_B) &&
+		    offset <= SLB_CACHE_ENTRIES) {
+			int i;
+			asm volatile("isync" : : : "memory");
+			for (i = 0; i < offset; i++) {
+				/* EA */
+				slbie_data = (unsigned long)
+					get_paca()->slb_cache[i] << SID_SHIFT;
+				slbie_data |= user_segment_size(slbie_data)
+						<< SLBIE_SSIZE_SHIFT;
+				slbie_data |= SLBIE_C; /* user slbs have C=1 */
+				asm volatile("slbie %0" : : "r" (slbie_data));
+			}
+			asm volatile("isync" : : : "memory");
+		} else {
+			__slb_flush_and_rebolt();
+		}
 
-	/* Workaround POWER5 < DD2.1 issue */
-	if (offset == 1 || offset > SLB_CACHE_ENTRIES)
-		asm volatile("slbie %0" : : "r" (slbie_data));
+		/* Workaround POWER5 < DD2.1 issue */
+		if (offset == 1 || offset > SLB_CACHE_ENTRIES)
+			asm volatile("slbie %0" : : "r" (slbie_data));
+
+		get_paca()->slb_cache_ptr = 0;
+	}
 
-	get_paca()->slb_cache_ptr = 0;
 	copy_mm_to_paca(mm);
 
 	/*
@@ -424,6 +437,9 @@ static void insert_slb_entry(unsigned long vsid, unsigned long ea,
 	asm volatile("slbmte %0, %1" : : "r" (vsid_data), "r" (esid_data)
 		     : "memory");
 
+	if (cpu_has_feature(CPU_FTR_ARCH_300))
+		return; /* ISAv3.0B and later does not use slb_cache */
+
 	/*
 	 * Now update slb cache entries
 	 */
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index 4ac5057ad439..dbbb7a59eaf8 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -285,11 +285,14 @@ slb_compare_rr_to_size:
 	 */
 	slbmte	r11,r10
 
-	/* we're done for kernel addresses */
 	crclr	4*cr0+eq		/* set result to "success" */
-	bgelr	cr7
+BEGIN_FTR_SECTION
+	blr				/* No SLB cache, see switch_slb */
+FTR_SECTION_ELSE
+	bgelr	cr7			/* we're done for kernel addresses */
+ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_300)
 
-	/* Update the slb cache */
+	/* Update the slb cache for user addresses */
 	lhz	r9,PACASLBCACHEPTR(r13)	/* offset = paca->slb_cache_ptr */
 	cmpldi	r9,SLB_CACHE_ENTRIES
 	bge	1f
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 81f84b7a3ebb..0d9033462e67 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2391,10 +2391,13 @@ static void dump_one_paca(int cpu)
 		}
 	}
 	DUMP(p, vmalloc_sllp, "%#-*x");
-	DUMP(p, slb_cache_ptr, "%#-*x");
-	for (i = 0; i < SLB_CACHE_ENTRIES; i++)
-		printf(" %-*s[%d] = 0x%016x\n",
-		       22, "slb_cache", i, p->slb_cache[i]);
+
+	if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+		DUMP(p, slb_cache_ptr, "%#-*x");
+		for (i = 0; i < SLB_CACHE_ENTRIES; i++)
+			printf(" %-*s[%d] = 0x%016x\n",
+			       22, "slb_cache", i, p->slb_cache[i]);
+	}
 
 	DUMP(p, rfi_flush_fallback_area, "%-*px");
 #endif
-- 
2.17.0

^ permalink raw reply related

* Re: [PATCH v7 7/9] powerpc/pseries: Dump the SLB contents on SLB MCE errors.
From: Mahesh Jagannath Salgaonkar @ 2018-08-13  4:17 UTC (permalink / raw)
  To: Nicholas Piggin
  Cc: linuxppc-dev, Aneesh Kumar K.V, Michael Ellerman, Michal Suchanek,
	Ananth Narayan, Laurent Dufour
In-Reply-To: <20180811143327.12255ffb@roar.ozlabs.ibm.com>

On 08/11/2018 10:03 AM, Nicholas Piggin wrote:
> On Tue, 07 Aug 2018 19:47:39 +0530
> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> 
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> If we get a machine check exceptions due to SLB errors then dump the
>> current SLB contents which will be very much helpful in debugging the
>> root cause of SLB errors. Introduce an exclusive buffer per cpu to hold
>> faulty SLB entries. In real mode mce handler saves the old SLB contents
>> into this buffer accessible through paca and print it out later in virtual
>> mode.
>>
>> With this patch the console will log SLB contents like below on SLB MCE
>> errors:
>>
>> [  507.297236] SLB contents of cpu 0x1
>> [  507.297237] Last SLB entry inserted at slot 16
>> [  507.297238] 00 c000000008000000 400ea1b217000500
>> [  507.297239]   1T  ESID=   c00000  VSID=      ea1b217 LLP:100
>> [  507.297240] 01 d000000008000000 400d43642f000510
>> [  507.297242]   1T  ESID=   d00000  VSID=      d43642f LLP:110
>> [  507.297243] 11 f000000008000000 400a86c85f000500
>> [  507.297244]   1T  ESID=   f00000  VSID=      a86c85f LLP:100
>> [  507.297245] 12 00007f0008000000 4008119624000d90
>> [  507.297246]   1T  ESID=       7f  VSID=      8119624 LLP:110
>> [  507.297247] 13 0000000018000000 00092885f5150d90
>> [  507.297247]  256M ESID=        1  VSID=   92885f5150 LLP:110
>> [  507.297248] 14 0000010008000000 4009e7cb50000d90
>> [  507.297249]   1T  ESID=        1  VSID=      9e7cb50 LLP:110
>> [  507.297250] 15 d000000008000000 400d43642f000510
>> [  507.297251]   1T  ESID=   d00000  VSID=      d43642f LLP:110
>> [  507.297252] 16 d000000008000000 400d43642f000510
>> [  507.297253]   1T  ESID=   d00000  VSID=      d43642f LLP:110
>> [  507.297253] ----------------------------------
>> [  507.297254] SLB cache ptr value = 3
>> [  507.297254] Valid SLB cache entries:
>> [  507.297255] 00 EA[0-35]=    7f000
>> [  507.297256] 01 EA[0-35]=        1
>> [  507.297257] 02 EA[0-35]=     1000
>> [  507.297257] Rest of SLB cache entries:
>> [  507.297258] 03 EA[0-35]=    7f000
>> [  507.297258] 04 EA[0-35]=        1
>> [  507.297259] 05 EA[0-35]=     1000
>> [  507.297260] 06 EA[0-35]=       12
>> [  507.297260] 07 EA[0-35]=    7f000
>>
>> Suggested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
>> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>> ---
>>
>> Changes in V7:
>> - Print slb cache ptr value and slb cache data
>> ---
>>  arch/powerpc/include/asm/book3s/64/mmu-hash.h |    7 ++
>>  arch/powerpc/include/asm/paca.h               |    4 +
>>  arch/powerpc/mm/slb.c                         |   73 +++++++++++++++++++++++++
>>  arch/powerpc/platforms/pseries/ras.c          |   10 +++
>>  arch/powerpc/platforms/pseries/setup.c        |   10 +++
>>  5 files changed, 103 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> index cc00a7088cf3..5a3fe282076d 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> @@ -485,9 +485,16 @@ static inline void hpte_init_pseries(void) { }
>>  
>>  extern void hpte_init_native(void);
>>  
>> +struct slb_entry {
>> +	u64	esid;
>> +	u64	vsid;
>> +};
>> +
>>  extern void slb_initialize(void);
>>  extern void slb_flush_and_rebolt(void);
>>  extern void slb_flush_and_rebolt_realmode(void);
>> +extern void slb_save_contents(struct slb_entry *slb_ptr);
>> +extern void slb_dump_contents(struct slb_entry *slb_ptr);
>>  
>>  extern void slb_vmalloc_update(void);
>>  extern void slb_set_size(u16 size);
>> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
>> index 7f22929ce915..233d25ff6f64 100644
>> --- a/arch/powerpc/include/asm/paca.h
>> +++ b/arch/powerpc/include/asm/paca.h
>> @@ -254,6 +254,10 @@ struct paca_struct {
>>  #endif
>>  #ifdef CONFIG_PPC_PSERIES
>>  	u8 *mce_data_buf;		/* buffer to hold per cpu rtas errlog */
>> +
>> +	/* Capture SLB related old contents in MCE handler. */
>> +	struct slb_entry *mce_faulty_slbs;
>> +	u16 slb_save_cache_ptr;
>>  #endif /* CONFIG_PPC_PSERIES */
>>  } ____cacheline_aligned;
>>  
>> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
>> index e89f675f1b5e..16a53689ffd4 100644
>> --- a/arch/powerpc/mm/slb.c
>> +++ b/arch/powerpc/mm/slb.c
>> @@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)
>>  	get_paca()->slb_cache_ptr = 0;
>>  }
>>  
>> +void slb_save_contents(struct slb_entry *slb_ptr)
>> +{
>> +	int i;
>> +	unsigned long e, v;
>> +
>> +	/* Save slb_cache_ptr value. */
>> +	get_paca()->slb_save_cache_ptr = get_paca()->slb_cache_ptr;
> 
> What's the point of saving this?

This is to know how many valid cache entries were present at the time of
SLB mutlihit. We use this index value while dumping the slb cahce entries.

> 
>> +
>> +	if (!slb_ptr)
>> +		return;
> 
> Can this ever happen?

May be Never. We allocate the memory at very early stage. But just added
as sanity check.

> 
>> +
>> +	for (i = 0; i < mmu_slb_size; i++) {
>> +		asm volatile("slbmfee  %0,%1" : "=r" (e) : "r" (i));
>> +		asm volatile("slbmfev  %0,%1" : "=r" (v) : "r" (i));
> 
> Does the UM say these instructions can cause machine checks if the SLB
> is corrupted? It talks about mfslb instruction causing MCE, but there
> seems to be no such instruction so I wonder if that's a typo for slbmf?
> 
> Seems like a parity error in the SLB should cause a MCE, at least,
> because it can't guarantee valid data for the instruction in that case
> (multi-hit may be different because you aren't searching by EA).
> 
> You could limit slb saving to a single level of recursion to avoid
> the problem.

Yeah, we could do this OR restrict slb saving only for SLB multi-hit.
Parity errors are anyway hardware errors. If parity error is transient
then saving of SLBs may not trigger another MCE. In that case old SLB
content would look ok even if we dump them on console. What do you say ?

> 
> Thanks,
> Nick
> 

^ permalink raw reply

* Re: [PATCH v2 1/2] powerpc/64s: move machine check SLB flushing to mm/slb.c
From: Mahesh Jagannath Salgaonkar @ 2018-08-13  4:27 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Gautham R . Shenoy, kvm-ppc, Aneesh Kumar K.V, Akshay Adiga
In-Reply-To: <20180810064249.13724-1-npiggin@gmail.com>

On 08/10/2018 12:12 PM, Nicholas Piggin wrote:
> The machine check code that flushes and restores bolted segments in
> real mode belongs in mm/slb.c. This will also be used by pseries
> machine check and idle code in future changes.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> 
> Since v1:
> - Restore the test for slb_shadow (mpe)
> ---
>  arch/powerpc/include/asm/book3s/64/mmu-hash.h |  3 ++
>  arch/powerpc/kernel/mce_power.c               | 26 +++++--------
>  arch/powerpc/mm/slb.c                         | 39 +++++++++++++++++++
>  3 files changed, 51 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> index 2f74bdc805e0..d4e398185b3a 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> @@ -497,6 +497,9 @@ extern void hpte_init_native(void);
> 
>  extern void slb_initialize(void);
>  extern void slb_flush_and_rebolt(void);
> +extern void slb_flush_all_realmode(void);
> +extern void __slb_restore_bolted_realmode(void);
> +extern void slb_restore_bolted_realmode(void);
> 
>  extern void slb_vmalloc_update(void);
>  extern void slb_set_size(u16 size);
> diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
> index d6756af6ec78..3497c8329c1d 100644
> --- a/arch/powerpc/kernel/mce_power.c
> +++ b/arch/powerpc/kernel/mce_power.c
> @@ -62,11 +62,8 @@ static unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
>  #ifdef CONFIG_PPC_BOOK3S_64
>  static void flush_and_reload_slb(void)
>  {
> -	struct slb_shadow *slb;
> -	unsigned long i, n;
> -
>  	/* Invalidate all SLBs */
> -	asm volatile("slbmte %0,%0; slbia" : : "r" (0));
> +	slb_flush_all_realmode();
> 
>  #ifdef CONFIG_KVM_BOOK3S_HANDLER
>  	/*
> @@ -76,22 +73,17 @@ static void flush_and_reload_slb(void)
>  	if (get_paca()->kvm_hstate.in_guest)
>  		return;
>  #endif
> -
> -	/* For host kernel, reload the SLBs from shadow SLB buffer. */
> -	slb = get_slb_shadow();
> -	if (!slb)
> +	if (early_radix_enabled())
>  		return;

Would we ever get MCE for SLB errors when radix is enabled ?

> 
> -	n = min_t(u32, be32_to_cpu(slb->persistent), SLB_MIN_SIZE);
> -
> -	/* Load up the SLB entries from shadow SLB */
> -	for (i = 0; i < n; i++) {
> -		unsigned long rb = be64_to_cpu(slb->save_area[i].esid);
> -		unsigned long rs = be64_to_cpu(slb->save_area[i].vsid);
> +	/*
> +	 * This probably shouldn't happen, but it may be possible it's
> +	 * called in early boot before SLB shadows are allocated.
> +	 */
> +	if (!get_slb_shadow())
> +		return;

Any reason you added above check here instead on mm/slb.c ? Should we
move above check inside slb_restore_bolted_realmode() ? I guess mm/slb.c
is right place for this check. This will also help pseries machine check
to avoid calling this extra check explicitly.

Thanks,
-Mahesh.

> 
> -		rb = (rb & ~0xFFFul) | i;
> -		asm volatile("slbmte %0,%1" : : "r" (rs), "r" (rb));
> -	}
> +	slb_restore_bolted_realmode();
>  }
>  #endif
> 
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index cb796724a6fc..0b095fa54049 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -90,6 +90,45 @@ static inline void create_shadowed_slbe(unsigned long ea, int ssize,
>  		     : "memory" );
>  }
> 
> +/*
> + * Insert bolted entries into SLB (which may not be empty, so don't clear
> + * slb_cache_ptr).
> + */
> +void __slb_restore_bolted_realmode(void)
> +{
> +	struct slb_shadow *p = get_slb_shadow();
> +	enum slb_index index;
> +
> +	 /* No isync needed because realmode. */
> +	for (index = 0; index < SLB_NUM_BOLTED; index++) {
> +		asm volatile("slbmte  %0,%1" :
> +		     : "r" (be64_to_cpu(p->save_area[index].vsid)),
> +		       "r" (be64_to_cpu(p->save_area[index].esid)));
> +	}
> +}
> +
> +/*
> + * Insert the bolted entries into an empty SLB.
> + * This is not the same as rebolt because the bolted segments are not
> + * changed, just loaded from the shadow area.
> + */
> +void slb_restore_bolted_realmode(void)
> +{
> +	__slb_restore_bolted_realmode();
> +	get_paca()->slb_cache_ptr = 0;
> +}
> +
> +/*
> + * This flushes all SLB entries including 0, so it must be realmode.
> + */
> +void slb_flush_all_realmode(void)
> +{
> +	/*
> +	 * This flushes all SLB entries including 0, so it must be realmode.
> +	 */
> +	asm volatile("slbmte %0,%0; slbia" : : "r" (0));
> +}
> +
>  static void __slb_flush_and_rebolt(void)
>  {
>  	/* If you change this make sure you change SLB_NUM_BOLTED
> 

^ permalink raw reply

* [PATCH V2] powerpc/mm/book3s/radix: Add mapping statistics
From: Aneesh Kumar K.V @ 2018-08-13  5:44 UTC (permalink / raw)
  To: npiggin, benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V

Add statistics that show how memory is mapped within the kernel linear mapping.
This is similar to commit 37cd944c8d8f ("s390/pgtable: add mapping statistics")

We don't do this with Hash translation mode. Hash uses one size (mmu_linear_psize)
to map the kernel linear mapping and we print the linear psize during boot as
below.

"Page orders: linear mapping = 24, virtual = 16, io = 16, vmemmap = 24"

A sample output looks like:

DirectMap4k:           0 kB
DirectMap64k:       18432 kB
DirectMap2M:     1030144 kB
DirectMap1G:    11534336 kB

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
Changes from V1:
 * updates from mpe to simplify the create_physical_mapping changes
 * Drop the dependency on patch that removed retry loop changes in
   the same function.

 arch/powerpc/include/asm/book3s/64/pgalloc.h |  7 +++++++
 arch/powerpc/include/asm/book3s/64/radix.h   |  3 +++
 arch/powerpc/mm/pgtable-book3s64.c           | 22 ++++++++++++++++++++
 arch/powerpc/mm/pgtable-radix.c              | 19 ++++++++++++-----
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgalloc.h b/arch/powerpc/include/asm/book3s/64/pgalloc.h
index 76234a14b97d..391ed2c3b697 100644
--- a/arch/powerpc/include/asm/book3s/64/pgalloc.h
+++ b/arch/powerpc/include/asm/book3s/64/pgalloc.h
@@ -227,4 +227,11 @@ static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
 
 #define check_pgt_cache()	do { } while (0)
 
+extern atomic_long_t direct_pages_count[MMU_PAGE_COUNT];
+static inline void update_page_count(int psize, long count)
+{
+	if (IS_ENABLED(CONFIG_PROC_FS))
+		atomic_long_add(count, &direct_pages_count[psize]);
+}
+
 #endif /* _ASM_POWERPC_BOOK3S_64_PGALLOC_H */
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index 77440e837869..7d1a3d1543fc 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -32,6 +32,9 @@
 #define RADIX_PUD_BAD_BITS		0x60000000000000e0UL
 #define RADIX_PGD_BAD_BITS		0x60000000000000e0UL
 
+#define RADIX_PMD_SHIFT		(PAGE_SHIFT + RADIX_PTE_INDEX_SIZE)
+#define RADIX_PUD_SHIFT		(RADIX_PMD_SHIFT + RADIX_PMD_INDEX_SIZE)
+#define RADIX_PGD_SHIFT		(RADIX_PUD_SHIFT + RADIX_PUD_INDEX_SIZE)
 /*
  * Size of EA range mapped by our pagetables.
  */
diff --git a/arch/powerpc/mm/pgtable-book3s64.c b/arch/powerpc/mm/pgtable-book3s64.c
index 78d0b3d5ebad..01d7c0f7c4f0 100644
--- a/arch/powerpc/mm/pgtable-book3s64.c
+++ b/arch/powerpc/mm/pgtable-book3s64.c
@@ -455,3 +455,25 @@ void pgtable_free_tlb(struct mmu_gather *tlb, void *table, int index)
 	return pgtable_free(table, index);
 }
 #endif
+
+#ifdef CONFIG_PROC_FS
+atomic_long_t direct_pages_count[MMU_PAGE_COUNT];
+
+void arch_report_meminfo(struct seq_file *m)
+{
+	/*
+	 * Hash maps the memory with one size mmu_linear_psize.
+	 * So don't bother to print these on hash
+	 */
+	if (!radix_enabled())
+		return;
+	seq_printf(m, "DirectMap4k:    %8lu kB\n",
+		   atomic_long_read(&direct_pages_count[MMU_PAGE_4K]) << 2);
+	seq_printf(m, "DirectMap64k:    %8lu kB\n",
+		   atomic_long_read(&direct_pages_count[MMU_PAGE_64K]) << 6);
+	seq_printf(m, "DirectMap2M:    %8lu kB\n",
+		   atomic_long_read(&direct_pages_count[MMU_PAGE_2M]) << 11);
+	seq_printf(m, "DirectMap1G:    %8lu kB\n",
+		   atomic_long_read(&direct_pages_count[MMU_PAGE_1G]) << 20);
+}
+#endif /* CONFIG_PROC_FS */
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index bba168d02235..7be99fd9af15 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -267,6 +267,7 @@ static int __meminit create_physical_mapping(unsigned long start,
 #else
 	int split_text_mapping = 0;
 #endif
+	int psize;
 
 	start = _ALIGN_UP(start, PAGE_SIZE);
 	for (addr = start; addr < end; addr += mapping_size) {
@@ -280,13 +281,17 @@ static int __meminit create_physical_mapping(unsigned long start,
 retry:
 		if (IS_ALIGNED(addr, PUD_SIZE) && gap >= PUD_SIZE &&
 		    mmu_psize_defs[MMU_PAGE_1G].shift &&
-		    PUD_SIZE <= max_mapping_size)
+		    PUD_SIZE <= max_mapping_size) {
 			mapping_size = PUD_SIZE;
-		else if (IS_ALIGNED(addr, PMD_SIZE) && gap >= PMD_SIZE &&
-			 mmu_psize_defs[MMU_PAGE_2M].shift)
+			psize = MMU_PAGE_1G;
+		} else if (IS_ALIGNED(addr, PMD_SIZE) && gap >= PMD_SIZE &&
+			   mmu_psize_defs[MMU_PAGE_2M].shift) {
 			mapping_size = PMD_SIZE;
-		else
+			psize = MMU_PAGE_2M;
+		} else {
 			mapping_size = PAGE_SIZE;
+			psize = mmu_virtual_psize;
+		}
 
 		if (split_text_mapping && (mapping_size == PUD_SIZE) &&
 			(addr <= __pa_symbol(__init_begin)) &&
@@ -297,8 +302,10 @@ static int __meminit create_physical_mapping(unsigned long start,
 
 		if (split_text_mapping && (mapping_size == PMD_SIZE) &&
 		    (addr <= __pa_symbol(__init_begin)) &&
-		    (addr + mapping_size) >= __pa_symbol(_stext))
+		    (addr + mapping_size) >= __pa_symbol(_stext)) {
 			mapping_size = PAGE_SIZE;
+			psize = mmu_virtual_psize;
+		}
 
 		if (mapping_size != previous_size) {
 			print_mapping(start, addr, previous_size);
@@ -316,6 +323,8 @@ static int __meminit create_physical_mapping(unsigned long start,
 		rc = __map_kernel_page(vaddr, addr, prot, mapping_size, nid, start, end);
 		if (rc)
 			return rc;
+
+		update_page_count(psize, 1);
 	}
 
 	print_mapping(start, addr, mapping_size);
-- 
2.17.1

^ permalink raw reply related

* Re: [PATCH] powerpc/powernv/idle: Fix build error
From: Alexey Kardashevskiy @ 2018-08-13  6:26 UTC (permalink / raw)
  To: Michael Ellerman, Aneesh Kumar K.V, npiggin, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <87k1oy8znu.fsf@concordia.ellerman.id.au>



On 10/08/2018 17:10, Michael Ellerman wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> 
>> Fix the below build error using strlcpy instead of strncpy
>>
>> In function 'pnv_parse_cpuidle_dt',
>>     inlined from 'pnv_init_idle_states' at arch/powerpc/platforms/powernv/idle.c:840:7,
>>     inlined from '__machine_initcall_powernv_pnv_init_idle_states' at arch/powerpc/platforms/powernv/idle.c:870:1:
>> arch/powerpc/platforms/powernv/idle.c:820:3: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation]
>>    strncpy(pnv_idle_states[i].name, temp_string[i],
>>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>     PNV_IDLE_NAME_LEN);
> 
> I'm curious why I haven't seen this? What compiler are you using?


gcc 8 does this.


> 
> cheers
> 
>> diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
>> index ecb002c5db83..35f699ebb662 100644
>> --- a/arch/powerpc/platforms/powernv/idle.c
>> +++ b/arch/powerpc/platforms/powernv/idle.c
>> @@ -817,7 +817,7 @@ static int pnv_parse_cpuidle_dt(void)
>>  		goto out;
>>  	}
>>  	for (i = 0; i < nr_idle_states; i++)
>> -		strncpy(pnv_idle_states[i].name, temp_string[i],
>> +		strlcpy(pnv_idle_states[i].name, temp_string[i],
>>  			PNV_IDLE_NAME_LEN);
>>  	nr_pnv_idle_states = nr_idle_states;
>>  	rc = 0;
>> -- 
>> 2.17.1

-- 
Alexey

^ permalink raw reply

* Re: [PATCH v6 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
From: Christoph Hellwig @ 2018-08-13  6:43 UTC (permalink / raw)
  To: Srikar Dronamraju
  Cc: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
	Michael Neuling, Vaidyanathan Srinivasan, Akshay Adiga,
	Shilpasri G Bhat, Oliver O'Halloran, Nicholas Piggin,
	Murilo Opsfelder Araujo, Anton Blanchard, linuxppc-dev,
	linux-kernel
In-Reply-To: <20180809132743.GB42474@linux.vnet.ibm.com>

On Thu, Aug 09, 2018 at 06:27:43AM -0700, Srikar Dronamraju wrote:
> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2018-08-09 11:02:07]:
> 
> > 
> >  int threads_per_core, threads_per_subcore, threads_shift;
> > +bool has_big_cores;
> >  cpumask_t threads_core_mask;
> >  EXPORT_SYMBOL_GPL(threads_per_core);
> >  EXPORT_SYMBOL_GPL(threads_per_subcore);
> >  EXPORT_SYMBOL_GPL(threads_shift);
> > +EXPORT_SYMBOL_GPL(has_big_cores);
> 
> Why do we need EXPORT_SYMBOL_GPL?

Because it is deeply internal, and in that matches the other related
exports.

^ permalink raw reply

* [PATCH v4] powerpc/topology: Get topology for shared processors at boot
From: Srikar Dronamraju @ 2018-08-13  7:25 UTC (permalink / raw)
  To: linuxppc-dev, Michael Ellerman
  Cc: Michael Bringmann, Manjunatha H R, Srikar Dronamraju,
	Anshuman Khandual
In-Reply-To: <1533703269-17861-1-git-send-email-srikar@linux.vnet.ibm.com>

On a shared lpar, Phyp will not update the cpu associativity at boot
time. Just after the boot system does recognize itself as a shared lpar and
trigger a request for correct cpu associativity. But by then the scheduler
would have already created/destroyed its sched domains.

This causes
- Broken load balance across Nodes causing islands of cores.
- Performance degradation esp if the system is lightly loaded
- dmesg to wrongly report all cpus to be in Node 0.
- Messages in dmesg saying borken topology.
- With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity
  node sched domain"), can cause rcu stalls at boot up.

>From a scheduler maintainer's perspective, moving cpus from one node to
another or creating more numa levels after boot is not appropriate
without some notification to the user space.
https://lore.kernel.org/lkml/20150406214558.GA38501@linux.vnet.ibm.com/T/#u

The sched_domains_numa_masks table which is used to generate cpumasks is
only created at boot time just before creating sched domains and never
updated.  Hence, its better to get the topology correct before the sched
domains are created.

For example on 64 core Power 8 shared lpar, dmesg reports

[    2.088360] Brought up 512 CPUs
[    2.088368] Node 0 CPUs: 0-511
[    2.088371] Node 1 CPUs:
[    2.088373] Node 2 CPUs:
[    2.088375] Node 3 CPUs:
[    2.088376] Node 4 CPUs:
[    2.088378] Node 5 CPUs:
[    2.088380] Node 6 CPUs:
[    2.088382] Node 7 CPUs:
[    2.088386] Node 8 CPUs:
[    2.088388] Node 9 CPUs:
[    2.088390] Node 10 CPUs:
[    2.088392] Node 11 CPUs:
...
[    3.916091] BUG: arch topology borken
[    3.916103]      the DIE domain not a subset of the NUMA domain
[    3.916105] BUG: arch topology borken
[    3.916106]      the DIE domain not a subset of the NUMA domain
...

numactl/lscpu output will still be correct with cores spreading across
all nodes.

Socket(s):             64
NUMA node(s):          12
Model:                 2.0 (pvr 004d 0200)
Model name:            POWER8 (architected), altivec supported
Hypervisor vendor:     pHyp
Virtualization type:   para
L1d cache:             64K
L1i cache:             32K
NUMA node0 CPU(s): 0-7,32-39,64-71,96-103,176-183,272-279,368-375,464-471
NUMA node1 CPU(s): 8-15,40-47,72-79,104-111,184-191,280-287,376-383,472-479
NUMA node2 CPU(s): 16-23,48-55,80-87,112-119,192-199,288-295,384-391,480-487
NUMA node3 CPU(s): 24-31,56-63,88-95,120-127,200-207,296-303,392-399,488-495
NUMA node4 CPU(s):     208-215,304-311,400-407,496-503
NUMA node5 CPU(s):     168-175,264-271,360-367,456-463
NUMA node6 CPU(s):     128-135,224-231,320-327,416-423
NUMA node7 CPU(s):     136-143,232-239,328-335,424-431
NUMA node8 CPU(s):     216-223,312-319,408-415,504-511
NUMA node9 CPU(s):     144-151,240-247,336-343,432-439
NUMA node10 CPU(s):    152-159,248-255,344-351,440-447
NUMA node11 CPU(s):    160-167,256-263,352-359,448-455

Currently on this lpar, the scheduler detects 2 levels of Numa and
created numa sched domains for all cpus, but it finds a single DIE
domain consisting of all cpus. Hence it deletes all numa sched domains.

To address this, detect the shared processor and update topology soon after
cpus are setup so that correct topology is updated just before scheduler
creates sched domain.

With the fix, dmesg reports

[    0.491336] numa: Node 0 CPUs: 0-7 32-39 64-71 96-103 176-183 272-279 368-375 464-471
[    0.491351] numa: Node 1 CPUs: 8-15 40-47 72-79 104-111 184-191 280-287 376-383 472-479
[    0.491359] numa: Node 2 CPUs: 16-23 48-55 80-87 112-119 192-199 288-295 384-391 480-487
[    0.491366] numa: Node 3 CPUs: 24-31 56-63 88-95 120-127 200-207 296-303 392-399 488-495
[    0.491374] numa: Node 4 CPUs: 208-215 304-311 400-407 496-503
[    0.491379] numa: Node 5 CPUs: 168-175 264-271 360-367 456-463
[    0.491384] numa: Node 6 CPUs: 128-135 224-231 320-327 416-423
[    0.491389] numa: Node 7 CPUs: 136-143 232-239 328-335 424-431
[    0.491394] numa: Node 8 CPUs: 216-223 312-319 408-415 504-511
[    0.491399] numa: Node 9 CPUs: 144-151 240-247 336-343 432-439
[    0.491404] numa: Node 10 CPUs: 152-159 248-255 344-351 440-447
[    0.491409] numa: Node 11 CPUs: 160-167 256-263 352-359 448-455

and lscpu would also report

Socket(s):             64
NUMA node(s):          12
Model:                 2.0 (pvr 004d 0200)
Model name:            POWER8 (architected), altivec supported
Hypervisor vendor:     pHyp
Virtualization type:   para
L1d cache:             64K
L1i cache:             32K
NUMA node0 CPU(s): 0-7,32-39,64-71,96-103,176-183,272-279,368-375,464-471
NUMA node1 CPU(s): 8-15,40-47,72-79,104-111,184-191,280-287,376-383,472-479
NUMA node2 CPU(s): 16-23,48-55,80-87,112-119,192-199,288-295,384-391,480-487
NUMA node3 CPU(s): 24-31,56-63,88-95,120-127,200-207,296-303,392-399,488-495
NUMA node4 CPU(s):     208-215,304-311,400-407,496-503
NUMA node5 CPU(s):     168-175,264-271,360-367,456-463
NUMA node6 CPU(s):     128-135,224-231,320-327,416-423
NUMA node7 CPU(s):     136-143,232-239,328-335,424-431
NUMA node8 CPU(s):     216-223,312-319,408-415,504-511
NUMA node9 CPU(s):     144-151,240-247,336-343,432-439
NUMA node10 CPU(s):    152-159,248-255,344-351,440-447
NUMA node11 CPU(s):    160-167,256-263,352-359,448-455

Previous attempt to solve this problem
https://patchwork.ozlabs.org/patch/530090/

Reported-by: Manjunatha H R <manjuhr1@in.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
---
Changelog v1->v2
 Fix compile warnings and checkpatch issues.

Changelog v2->v3
 Fix compile warnings on !CONFIG_SMP

Changelog v3->v4
 Now do early topology init on shared processor.  Earlier we used to do only
 for vphn enabled.  However we want this update to happen even when
 topology_updates=off.  Changed patch title accordingly

 arch/powerpc/include/asm/topology.h |  5 +++++
 arch/powerpc/kernel/smp.c           |  6 ++++++
 arch/powerpc/mm/numa.c              | 22 ++++++++++++++--------
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 16b077801a5f..a4a718dbfec6 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -92,6 +92,7 @@ extern int stop_topology_update(void);
 extern int prrn_is_enabled(void);
 extern int find_and_online_cpu_nid(int cpu);
 extern int timed_topology_update(int nsecs);
+extern void __init shared_proc_topology_init(void);
 #else
 static inline int start_topology_update(void)
 {
@@ -113,6 +114,10 @@ static inline int timed_topology_update(int nsecs)
 {
 	return 0;
 }
+
+#ifdef CONFIG_SMP
+static inline void shared_proc_topology_init(void) {}
+#endif
 #endif /* CONFIG_NUMA && CONFIG_PPC_SPLPAR */
 
 #include <asm-generic/topology.h>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 4794d6b4f4d2..b3142c7b9c31 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1156,6 +1156,11 @@ void __init smp_cpus_done(unsigned int max_cpus)
 	if (smp_ops && smp_ops->bringup_done)
 		smp_ops->bringup_done();
 
+	/*
+	 * On a shared LPAR, associativity needs to be requested.
+	 * Hence, get numa topology before dumping cpu topology
+	 */
+	shared_proc_topology_init();
 	dump_numa_cpu_topology();
 
 	/*
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 0c7e05d89244..16250fb25411 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1551,6 +1551,15 @@ int prrn_is_enabled(void)
 	return prrn_enabled;
 }
 
+void __init shared_proc_topology_init(void)
+{
+	if (lppaca_shared_proc(get_lppaca())) {
+		bitmap_fill(cpumask_bits(&cpu_associativity_changes_mask),
+			    nr_cpumask_bits);
+		numa_update_cpu_topology(false);
+	}
+}
+
 static int topology_read(struct seq_file *file, void *v)
 {
 	if (vphn_enabled || prrn_enabled)
-- 
2.17.1

^ permalink raw reply related

* [PATCH] ocxl: Fix access to the AFU Descriptor Data
From: Christophe Lombard @ 2018-08-13  9:01 UTC (permalink / raw)
  To: linuxppc-dev, fbarrat, vaibhav, andrew.donnellan

From: Christophe Lombard <christophe_lombard@fr.ibm.cm>

The AFU Information DVSEC capability is a means to extract common,
general information about all of the AFUs associated with a Function
independent of the specific functionality that each AFU provides.

This patch fixes the access to the AFU Descriptor Data indexed by the
AFU Info Index field.

Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices")

Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
---
 drivers/misc/ocxl/config.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index 2e30de9..de01623 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -280,7 +280,9 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
 	u32 val;
 	int rc, templ_major, templ_minor, len;
 
-	pci_write_config_word(dev, fn->dvsec_afu_info_pos, afu_idx);
+	pci_write_config_word(dev,
+			      fn->dvsec_afu_info_pos + OCXL_DVSEC_AFU_INFO_AFU_IDX,
+			      afu_idx);
 	rc = read_afu_info(dev, fn, OCXL_DVSEC_TEMPL_VERSION, &val);
 	if (rc)
 		return rc;
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH] ocxl: Fix access to the AFU Descriptor Data
From: Andrew Donnellan @ 2018-08-13  9:48 UTC (permalink / raw)
  To: Christophe Lombard, linuxppc-dev, fbarrat, vaibhav
In-Reply-To: <1534150891-19394-1-git-send-email-clombard@linux.vnet.ibm.com>

On 13/08/18 19:01, Christophe Lombard wrote:
> From: Christophe Lombard <christophe_lombard@fr.ibm.cm>

Your git committer email should probably match your sign-off email.

> 
> The AFU Information DVSEC capability is a means to extract common,
> general information about all of the AFUs associated with a Function
> independent of the specific functionality that each AFU provides.
> 
> This patch fixes the access to the AFU Descriptor Data indexed by the
> AFU Info Index field.
> 
> Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices")
> 
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>

This looks like it should go to stable? I assume the reason we haven't 
noticed this previously is because we have not been testing with 
multi-AFU cards.

> ---
>   drivers/misc/ocxl/config.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
> index 2e30de9..de01623 100644
> --- a/drivers/misc/ocxl/config.c
> +++ b/drivers/misc/ocxl/config.c
> @@ -280,7 +280,9 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
>   	u32 val;
>   	int rc, templ_major, templ_minor, len;
>   
> -	pci_write_config_word(dev, fn->dvsec_afu_info_pos, afu_idx);
> +	pci_write_config_word(dev,
> +			      fn->dvsec_afu_info_pos + OCXL_DVSEC_AFU_INFO_AFU_IDX,
> +			      afu_idx);

pci_write_config_byte() would be more appropriate here (see 
ocxl_config_read_afu() at line 454)

>   	rc = read_afu_info(dev, fn, OCXL_DVSEC_TEMPL_VERSION, &val);
>   	if (rc)
>   		return rc;
> 

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

^ permalink raw reply

* Re: [PATCH] ocxl: Fix access to the AFU Descriptor Data
From: Frederic Barrat @ 2018-08-13 10:21 UTC (permalink / raw)
  To: Andrew Donnellan, Christophe Lombard, linuxppc-dev, fbarrat,
	vaibhav
In-Reply-To: <85eab07a-5ef8-0d0a-fe82-9860ae84015e@au1.ibm.com>



Le 13/08/2018 à 11:48, Andrew Donnellan a écrit :
> On 13/08/18 19:01, Christophe Lombard wrote:
>> From: Christophe Lombard <christophe_lombard@fr.ibm.cm>
> 
> Your git committer email should probably match your sign-off email.
> 
>>
>> The AFU Information DVSEC capability is a means to extract common,
>> general information about all of the AFUs associated with a Function
>> independent of the specific functionality that each AFU provides.
>>
>> This patch fixes the access to the AFU Descriptor Data indexed by the
>> AFU Info Index field.
>>
>> Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices")
>>
>> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> 
> This looks like it should go to stable? I assume the reason we haven't 
> noticed this previously is because we have not been testing with 
> multi-AFU cards.

Yes, it's hidden until we have more than one AFU per function. Also, the 
field we overwrite at the wrong offset is read-only, so it goes undetected.

   Fred




> 
>> ---
>>   drivers/misc/ocxl/config.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
>> index 2e30de9..de01623 100644
>> --- a/drivers/misc/ocxl/config.c
>> +++ b/drivers/misc/ocxl/config.c
>> @@ -280,7 +280,9 @@ int ocxl_config_check_afu_index(struct pci_dev *dev,
>>       u32 val;
>>       int rc, templ_major, templ_minor, len;
>> -    pci_write_config_word(dev, fn->dvsec_afu_info_pos, afu_idx);
>> +    pci_write_config_word(dev,
>> +                  fn->dvsec_afu_info_pos + OCXL_DVSEC_AFU_INFO_AFU_IDX,
>> +                  afu_idx);
> 
> pci_write_config_byte() would be more appropriate here (see 
> ocxl_config_read_afu() at line 454)
> 
>>       rc = read_afu_info(dev, fn, OCXL_DVSEC_TEMPL_VERSION, &val);
>>       if (rc)
>>           return rc;
>>
> 

^ permalink raw reply

* Re: [RFC,v2] powerpc: xmon: Add address lookup for percpu symbols
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Boqun Feng, linux-kernel, linuxppc-dev
  Cc: Douglas Miller, Boqun Feng, Rashmica Gupta, Paul Mackerras,
	Aneesh Kumar K.V, Andrew Donnellan
In-Reply-To: <20161122092033.7869-1-boqun.feng@gmail.com>

On Tue, 2016-11-22 at 09:20:09 UTC, Boqun Feng wrote:
> Currently, in xmon, there is no obvious way to get an address for a
> percpu symbol for a particular cpu. Having such an ability would be good
> for debugging the system when percpu variables got involved.
> 
> Therefore, this patch introduces a new xmon command "lp" to lookup the
> address for percpu symbols. Usage of "lp" is similar to "ls", except
> that we could add a cpu number to choose the variable of which cpu we
> want to lookup. If no cpu number is given, lookup for current cpu.
> 
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/302c7b0c4ff5aed585419603f835de

cheers

^ permalink raw reply

* Re: powerpc: Use common error handling code in setup_new_fdt()
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: SF Markus Elfring, linuxppc-dev, Benjamin Herrenschmidt,
	Borislav Petkov, Brijesh Singh, Josh Sklar, Kees Cook,
	Paul Mackerras, Thiago Jung Bauermann, Thomas Gleixner,
	Tom Lendacky
  Cc: kernel-janitors, LKML
In-Reply-To: <0dd9d938-8d89-f0e0-f05f-9a3e5dc42a57@users.sourceforge.net>

On Sun, 2018-03-11 at 08:16:47 UTC, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 11 Mar 2018 09:03:42 +0100
> 
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/baedcdf5054c151a33e34392af7d8c

cheers

^ permalink raw reply

* Re: [16/19] powerpc/powermac: Add missing include of header pmac.h
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Mathieu Malaterre, linux-kernel, kvm-ppc, Paul Mackerras,
	linuxppc-dev
In-Reply-To: <20180322202007.23088-17-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Thu, 2018-03-22 at 20:20:02 UTC, Mathieu Malaterre wrote:
> The header `pmac.h` was not included, leading to the following warnings,
> treated as error with W=1:
> 
>   arch/powerpc/platforms/powermac/time.c:69:13: error: no previous prototype for ‘pmac_time_init’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/time.c:207:15: error: no previous prototype for ‘pmac_get_boot_time’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/time.c:222:6: error: no previous prototype for ‘pmac_get_rtc_time’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/time.c:240:5: error: no previous prototype for ‘pmac_set_rtc_time’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/time.c:259:12: error: no previous prototype for ‘via_calibrate_decr’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/time.c:311:13: error: no previous prototype for ‘pmac_calibrate_decr’ [-Werror=missing-prototypes]
> 
> The function `via_calibrate_decr` was made static to silence a warning.
> 
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2fff0f07b8441a481eb5fc0bfcd0e4

cheers

^ permalink raw reply

* Re: cxl: remove a dead branch
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Mathieu Malaterre, Frederic Barrat
  Cc: Mathieu Malaterre, linuxppc-dev, Christophe Lombard,
	Andrew Donnellan
In-Reply-To: <20180322210528.22017-1-malat@debian.org>

On Thu, 2018-03-22 at 21:05:28 UTC, Mathieu Malaterre wrote:
> In commit 14baf4d9c739 ("cxl: Add guest-specific code") the following code
> was added:
> 
> 	if (afu->crs_len < 0) {
> 		dev_err(&afu->dev, "Unexpected configuration record size value\n");
> 		return -EINVAL;
> 	}
> 
> However the variable `crs_len` is of type u64 and cannot be compared < 0.
> Remove the dead code section. Fix the following warning treated as error
> with W=1:
> 
> ../drivers/misc/cxl/guest.c:919:19: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
> 
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e4ecafb14fd9cd77d8f4320af1922e

cheers

^ permalink raw reply

* Re: [v2,02/19] powerpc/powermac: Mark variable x as unused
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180328193028.823-1-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On Wed, 2018-03-28 at 19:30:28 UTC, Mathieu Malaterre wrote:
> Since the value of x is never intended to be read, remove it. Fix warning
> treated as error with W=1:
> 
>   arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable ‘x’ set but not used [-Werror=unused-but-set-variable]
> 
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/8921305c1ec9d9ea23e5f8eac30630

cheers

^ permalink raw reply

* Re: [v2,07/19] powerpc/powermac: Make some functions static
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180328193935.1338-1-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Wed, 2018-03-28 at 19:39:35 UTC, Mathieu Malaterre wrote:
> These functions can all be static, make it so. Fix warnings treated as
> errors with W=1:
> 
>   arch/powerpc/platforms/powermac/pci.c:1022:6: error: no previous prototype for ‘pmac_pci_fixup_ohci’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/pci.c:1057:6: error: no previous prototype for ‘pmac_pci_fixup_cardbus’ [-Werror=missing-prototypes]
>   arch/powerpc/platforms/powermac/pci.c:1094:6: error: no previous prototype for ‘pmac_pci_fixup_pciata’ [-Werror=missing-prototypes]
> 
> Remove has_address declaration and assignment since not used. Also add gcc
> attribute unused to fix a warning treated as error with W=1:
> 
>   arch/powerpc/platforms/powermac/pci.c:784:19: error: variable ‘has_address’ set but not used [-Werror=unused-but-set-variable]
>   arch/powerpc/platforms/powermac/pci.c:907:22: error: variable ‘ht’ set but not used [-Werror=unused-but-set-variable]
> 
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/618a89d738fdd97f6fc58b7b666c7a

cheers

^ permalink raw reply

* Re: [v3,03/19] powerpc: Move `path` variable inside DEBUG_PROM
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180404200836.27446-1-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Wed, 2018-04-04 at 20:08:35 UTC, Mathieu Malaterre wrote:
> Add gcc attribute unused for two variables. Fix warnings treated as errors
> with W=1:
> 
>   arch/powerpc/kernel/prom_init.c:1388:8: error: variable ‘path’ set but not used [-Werror=unused-but-set-variable]
> 
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/eab00a208eb63d863b6cc0a03f68b4

cheers

^ permalink raw reply

* Re: [10/15] tty: hvc: use mutex instead of spinlock for hvc_structs lock
From: Michael Ellerman @ 2018-08-13 11:22 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Jiri Slaby, linux-kernel, Nicholas Piggin, Greg Kroah-Hartman
In-Reply-To: <20180430145558.4308-11-npiggin@gmail.com>

On Mon, 2018-04-30 at 14:55:53 UTC, Nicholas Piggin wrote:
> This allows hvc operations to sleep under the lock.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a9bf5c8a271b9a954709b7ada1bd25

cheers

^ permalink raw reply

* Re: [11/15] tty: hvc: hvc_poll break hv read loop
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Jiri Slaby, linux-kernel, Nicholas Piggin, Greg Kroah-Hartman
In-Reply-To: <20180430145558.4308-12-npiggin@gmail.com>

On Mon, 2018-04-30 at 14:55:54 UTC, Nicholas Piggin wrote:
> Avoid looping with the spinlock held while there is read data
> being returned from the hv driver. Instead note if the entire
> size returned by tty_buffer_request_room was read, and request
> another read poll.
> 
> This limits the critical section lengths, and provides more
> even service to other consoles in case there is a pathological
> condition.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/ec97eaad1383ab2500fcf9a07ade60

cheers

^ permalink raw reply

* Re: [12/15] tty: hvc: hvc_poll may sleep
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Jiri Slaby, linux-kernel, Nicholas Piggin, Greg Kroah-Hartman
In-Reply-To: <20180430145558.4308-13-npiggin@gmail.com>

On Mon, 2018-04-30 at 14:55:55 UTC, Nicholas Piggin wrote:
> Introduce points where hvc_poll drops the lock, enables interrupts,
> and reschedules.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/cfb5946b55f1dfd19e042feae1fbff

cheers

^ permalink raw reply

* Re: [13/15] tty: hvc: hvc_write may sleep
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Jiri Slaby, linux-kernel, Nicholas Piggin, Greg Kroah-Hartman
In-Reply-To: <20180430145558.4308-14-npiggin@gmail.com>

On Mon, 2018-04-30 at 14:55:56 UTC, Nicholas Piggin wrote:
> Rework the hvc_write loop to drop and re-take the spinlock on each
> iteration, add a cond_resched. Don't bother with an initial hvc_push
> initially, which makes the logic simpler -- just do a hvc_push on
> each time around the loop.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/550ddadcc7580ec2a6c22d4ed04291

cheers

^ permalink raw reply

* Re: [14/15] tty: hvc: introduce the hv_ops.flush operation for hvc drivers
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
  Cc: Jiri Slaby, linux-kernel, Nicholas Piggin, Greg Kroah-Hartman
In-Reply-To: <20180430145558.4308-15-npiggin@gmail.com>

On Mon, 2018-04-30 at 14:55:57 UTC, Nicholas Piggin wrote:
> Use .flush to wait for drivers to flush their console outside of
> the spinlock, to reduce lock/irq latencies.
> 
> Flush the hvc console driver after each write, which can help
> messages make it out to the console after a crash.
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/9f65b81f36e31563c5a5e4df3b3b8b

cheers

^ permalink raw reply

* Re: powerpc/mm: remove warning about ‘type’ being set
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Kate Stewart, Greg Kroah-Hartman, Mathieu Malaterre, linux-kernel,
	Paul Mackerras, Philippe Ombredanne, Thomas Gleixner,
	linuxppc-dev
In-Reply-To: <20180622192749.24954-1-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Fri, 2018-06-22 at 19:27:47 UTC, Mathieu Malaterre wrote:
> ‘type’ is only used when CONFIG_DEBUG_HIGHMEM is set. So add a possibly
> unused tag to variable. Remove warning treated as error with W=1:
> 
>   arch/powerpc/mm/highmem.c:59:6: error: variable ‘type’ set but not used [-Werror=unused-but-set-variable]
> 
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/fce278af81daf8599f9e94883cbe43

cheers

^ permalink raw reply

* Re: powerpc: include setup.h header file to fix warnings
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Mathieu Malaterre
  Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180622192655.23464-1-malat@debian.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Fri, 2018-06-22 at 19:26:53 UTC, Mathieu Malaterre wrote:
> Make sure to include setup.h to provide the following prototypes:
> 
> - irqstack_early_init
> - setup_power_save
> - initialize_cache_info
> 
> Fix the following warnings (treated as error in W=1):
> 
>   arch/powerpc/kernel/setup_32.c:198:13: error: no previous prototype for ‘irqstack_early_init’ [-Werror=missing-prototypes]
>   arch/powerpc/kernel/setup_32.c:238:13: error: no previous prototype for ‘setup_power_save’ [-Werror=missing-prototypes]
>   arch/powerpc/kernel/setup_32.c:253:13: error: no previous prototype for ‘initialize_cache_info’ [-Werror=missing-prototypes]
> 
> Signed-off-by: Mathieu Malaterre <malat@debian.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/f2c6d0d1092e3da2bd36c768777e88

cheers

^ permalink raw reply

* Re: [1/2] powerpc: Allow memory that has been hot-removed to be hot-added
From: Michael Ellerman @ 2018-08-13 11:23 UTC (permalink / raw)
  To: Rashmica Gupta, linuxppc-dev, mikey, benh, paulus, bsingharora
  Cc: Rashmica Gupta
In-Reply-To: <20180803060601.724-1-rashmica.g@gmail.com>

On Fri, 2018-08-03 at 06:06:00 UTC, Rashmica Gupta wrote:
> This patch allows the memory removed by memtrace to be readded to the
> kernel. So now you don't have to reboot your system to add the memory
> back to the kernel or to have a different amount of memory removed.
> 
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> Tested-by: Michael Neuling <mikey@neuling.org>

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/d3da701d3308ce1fa457f32c6c9e21

cheers

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox