[PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

From: Natalie Protasevich <protasnb@gmail.com>

This patch allows to disable ptc.g. The code used to be in the kernel, then 
was removed in 2.4 since the bug that it was fixing has gone away. However, 
some large system vendors now want this capability available through a means 
that can be controlled by the platform in the event that there is an issue 
with either processor or their chipset where global ptc.g is not operational.  
They want the mechanism for future platforms to work around such issues. It 
is also needed for platform makers when they deliberately do not use the 
global cache purge in their chipset implementation. (For such cases, Intel 
provided a SAL table entry to specify if ptc.g is allowed and how many).


---

 arch/ia64/kernel/smp.c |   49 ++++++++++++++++++++++++++++++++
 arch/ia64/mm/tlb.c     |   75 
++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 123 insertions(+), 1 deletion(-)

diff -puN arch/ia64/mm/tlb.c~ptcg arch/ia64/mm/tlb.c
--- linux-2.6.23-rc4/arch/ia64/mm/tlb.c~ptcg	2007-08-30 
11:58:40.000000000 -0700
+++ linux-2.6.23-rc4-nataliep/arch/ia64/mm/tlb.c	2007-08-30 
11:58:40.000000000 -0700
@@ -18,6 +18,7 @@
 #include <linux/smp.h>
 #include <linux/mm.h>
 #include <linux/bootmem.h>
+#include <linux/irq.h>
 
 #include <asm/delay.h>
 #include <asm/mmu_context.h>
@@ -83,6 +84,73 @@ wrap_mmu_context (struct mm_struct *mm)
 	local_flush_tlb_all();
 }
 
+static int noptcg;
+
+static void __init noptcg_setup(char *str)
+{
+	noptcg = 1;
+}
+__setup("noptcg", noptcg_setup);
+
+unsigned long	flush_end, flush_start, flush_nbits, flush_rid;
+atomic_t flush_cpu_count;
+
+/*
+ * flush_tlb_no_ptcg is called with ptcg_lock locked
+ */
+static inline void
+flush_tlb_no_ptcg (unsigned long start, unsigned long end, unsigned long 
nbits)
+{
+	extern void smp_send_flush_tlb (void);
+	unsigned long saved_tpr = 0;
+	unsigned long flags;
+	int cpus = num_online_cpus();
+
+	/*
+	 * Sometimes this is called with interrupts disabled and causes
+	 * deadlock; to avoid this we enable interrupt and raise the TPR
+	 * to enable ONLY IPI.
+	 */
+	local_save_flags(flags);
+	if (!(flags & IA64_PSR_I)) {
+		saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
+		ia64_srlz_d();
+		ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
+		ia64_srlz_d();
+		local_irq_enable();
+	}
+
+	flush_rid = ia64_get_rr(start);
+	ia64_srlz_d();
+	flush_start = start;
+	flush_end = end;
+	flush_nbits = nbits;
+	atomic_set(&flush_cpu_count, cpus - 1);
+	smp_send_flush_tlb();
+	/*
+	 * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
+	 */
+	do {
+		asm volatile ("ptc.l %0,%1" :: "r"(start), "r"(nbits<<2) : "memory");
+		start += (1UL << nbits);
+	} while (start < end);
+
+	ia64_srlz_i();			/* srlz.i implies srlz.d */
+
+	/*
+	 * Wait for other CPUs to finish purging entries.
+	 */
+	while (atomic_read(&flush_cpu_count)) {
+		/* Nothing */
+	}
+
+	if (!(flags & IA64_PSR_I)) {
+		local_irq_disable();
+	 	ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
+		ia64_srlz_d();
+	}
+}
+
 void
 ia64_global_tlb_purge (struct mm_struct *mm, unsigned long start,
 		       unsigned long end, unsigned long nbits)
@@ -96,7 +164,9 @@ ia64_global_tlb_purge (struct mm_struct 
 
 	/* HW requires global serialization of ptc.ga.  */
 	spin_lock(&ptcg_lock);
-	{
+	if (noptcg)
+		flush_tlb_no_ptcg(start, end, nbits);
+	else {
 		do {
 			/*
 			 * Flush ALAT entries also.
@@ -109,6 +179,9 @@ ia64_global_tlb_purge (struct mm_struct 
 	spin_unlock(&ptcg_lock);
 }
 
+unsigned long	flush_end, flush_start, flush_nbits, flush_rid;
+atomic_t flush_cpu_count;
+
 void
 local_flush_tlb_all (void)
 {
diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
--- linux-2.6.23-rc4/arch/ia64/kernel/smp.c~ptcg	2007-08-30 
11:58:40.000000000 -0700
+++ linux-2.6.23-rc4-nataliep/arch/ia64/kernel/smp.c	2007-08-30 
11:58:40.000000000 -0700
@@ -79,6 +79,7 @@ static volatile struct call_data_struct 
 
 #define IPI_CALL_FUNC		0
 #define IPI_CPU_STOP		1
+#define IPI_FLUSH_TLB		2
 #define IPI_KDUMP_CPU_STOP	3
 
 /* This needs to be cacheline aligned because it is written to by *other* 
CPUs.  */
@@ -174,6 +175,47 @@ handle_IPI (int irq, void *dev_id)
 				unw_init_running(kdump_cpu_freeze, NULL);
 				break;
 #endif
+
+			      case IPI_FLUSH_TLB:
+			      {
+				extern unsigned long flush_start, flush_end, flush_nbits, flush_rid;
+				extern atomic_t flush_cpu_count;
+				unsigned long saved_rid = ia64_get_rr(flush_start);
+				unsigned long end = flush_end;
+				unsigned long start = flush_start;
+				unsigned long nbits = flush_nbits;
+	
+				/*
+				 * Current CPU may be running with different RID so we need to
+				 * reload the RID of flushed address.  Purging the translation
+				 * also needs ALAT invalidation; we do not need "invala" here
+				 * since it is done in ia64_leave_kernel.
+				 */
+				ia64_srlz_d();
+				if (saved_rid != flush_rid) {
+					ia64_set_rr(flush_start, flush_rid);
+					ia64_srlz_d();
+				}
+
+				do {
+					/*
+					 * Purge local TLB entries.
+				 	 */
+					__asm__ __volatile__ ("ptc.l %0,%1" ::
+							      "r"(start), "r"(nbits<<2) : "memory");
+					start += (1UL << nbits);
+				} while (start < end);
+
+				ia64_barrier();
+				ia64_srlz_i();			/* srlz.i implies srlz.d */
+
+				if (saved_rid != flush_rid) {
+					ia64_set_rr(flush_start, saved_rid);
+					ia64_srlz_d();
+				}
+				atomic_dec(&flush_cpu_count);
+				break;
+			      }
 			      default:
 				printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);
 				break;
@@ -317,6 +359,13 @@ smp_flush_tlb_cpumask(cpumask_t xcpumask
 }
 
 void
+smp_send_flush_tlb (void)
+{
+	send_IPI_allbutself(IPI_FLUSH_TLB);
+}
+
+
+void
 smp_flush_tlb_all (void)
 {
 	on_each_cpu((void (*)(void *))local_flush_tlb_all, NULL, 1, 1);
_

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be

[Zou Nan hai]

On Fri, 2007-08-31 at 04:38, Natalie Protasevich wrote:
> From: Natalie Protasevich <protasnb@gmail.com>
> 
> This patch allows to disable ptc.g. The code used to be in the kernel, then 
> was removed in 2.4 since the bug that it was fixing has gone away. However, 
> some large system vendors now want this capability available through a means 
> that can be controlled by the platform in the event that there is an issue 
> with either processor or their chipset where global ptc.g is not operational.  
> They want the mechanism for future platforms to work around such issues. It 
> is also needed for platform makers when they deliberately do not use the 
> global cache purge in their chipset implementation. (For such cases, Intel 
> provided a SAL table entry to specify if ptc.g is allowed and how many).
> 
> 
> ---
> 
>  arch/ia64/kernel/smp.c |   49 ++++++++++++++++++++++++++++++++
>  arch/ia64/mm/tlb.c     |   75 
> ++++++++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 123 insertions(+), 1 deletion(-)
> 
> diff -puN arch/ia64/mm/tlb.c~ptcg arch/ia64/mm/tlb.c
> --- linux-2.6.23-rc4/arch/ia64/mm/tlb.c~ptcg	2007-08-30 
> 11:58:40.000000000 -0700
> +++ linux-2.6.23-rc4-nataliep/arch/ia64/mm/tlb.c	2007-08-30 
> 11:58:40.000000000 -0700
> @@ -18,6 +18,7 @@
>  #include <linux/smp.h>
>  #include <linux/mm.h>
>  #include <linux/bootmem.h>
> +#include <linux/irq.h>
>  
>  #include <asm/delay.h>
>  #include <asm/mmu_context.h>
> @@ -83,6 +84,73 @@ wrap_mmu_context (struct mm_struct *mm)
>  	local_flush_tlb_all();
>  }
>  
> +static int noptcg;
> +
> +static void __init noptcg_setup(char *str)
> +{
> +	noptcg = 1;
> +}
> +__setup("noptcg", noptcg_setup);
> +
> +unsigned long	flush_end, flush_start, flush_nbits, flush_rid;
> +atomic_t flush_cpu_count;
> +
> +/*
> + * flush_tlb_no_ptcg is called with ptcg_lock locked
> + */
> +static inline void
> +flush_tlb_no_ptcg (unsigned long start, unsigned long end, unsigned long 
> nbits)
> +{
> +	extern void smp_send_flush_tlb (void);
> +	unsigned long saved_tpr = 0;
> +	unsigned long flags;
> +	int cpus = num_online_cpus();
> +
> +	/*
> +	 * Sometimes this is called with interrupts disabled and causes
> +	 * deadlock; to avoid this we enable interrupt and raise the TPR
> +	 * to enable ONLY IPI.
> +	 */
> +	local_save_flags(flags);
> +	if (!(flags & IA64_PSR_I)) {
> +		saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
> +		ia64_srlz_d();
> +		ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
> +		ia64_srlz_d();
> +		local_irq_enable();
> +	}
> +
> +	flush_rid = ia64_get_rr(start);
> +	ia64_srlz_d();
> +	flush_start = start;
> +	flush_end = end;
> +	flush_nbits = nbits;
> +	atomic_set(&flush_cpu_count, cpus - 1);
> +	smp_send_flush_tlb();
> +	/*
> +	 * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
> +	 */
> +	do {
> +		asm volatile ("ptc.l %0,%1" :: "r"(start), "r"(nbits<<2) : "memory");
> +		start += (1UL << nbits);
> +	} while (start < end);
> +
> +	ia64_srlz_i();			/* srlz.i implies srlz.d */
> +
> +	/*
> +	 * Wait for other CPUs to finish purging entries.
> +	 */
> +	while (atomic_read(&flush_cpu_count)) {
> +		/* Nothing */
> +	}
> +
> +	if (!(flags & IA64_PSR_I)) {
> +		local_irq_disable();
> +	 	ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
> +		ia64_srlz_d();
> +	}
> +}
> +
>  void
>  ia64_global_tlb_purge (struct mm_struct *mm, unsigned long start,
>  		       unsigned long end, unsigned long nbits)
> @@ -96,7 +164,9 @@ ia64_global_tlb_purge (struct mm_struct 
>  
>  	/* HW requires global serialization of ptc.ga.  */
>  	spin_lock(&ptcg_lock);
> -	{
> +	if (noptcg)
> +		flush_tlb_no_ptcg(start, end, nbits);
> +	else {
>  		do {
>  			/*
>  			 * Flush ALAT entries also.
> @@ -109,6 +179,9 @@ ia64_global_tlb_purge (struct mm_struct 
>  	spin_unlock(&ptcg_lock);
>  }
>  
> +unsigned long	flush_end, flush_start, flush_nbits, flush_rid;
> +atomic_t flush_cpu_count;
> +
>  void
>  local_flush_tlb_all (void)
>  {
> diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
> --- linux-2.6.23-rc4/arch/ia64/kernel/smp.c~ptcg	2007-08-30 
> 11:58:40.000000000 -0700
> +++ linux-2.6.23-rc4-nataliep/arch/ia64/kernel/smp.c	2007-08-30 
> 11:58:40.000000000 -0700
> @@ -79,6 +79,7 @@ static volatile struct call_data_struct 
>  
>  #define IPI_CALL_FUNC		0
>  #define IPI_CPU_STOP		1
> +#define IPI_FLUSH_TLB		2
>  #define IPI_KDUMP_CPU_STOP	3
>  
>  /* This needs to be cacheline aligned because it is written to by *other* 
> CPUs.  */
> @@ -174,6 +175,47 @@ handle_IPI (int irq, void *dev_id)
>  				unw_init_running(kdump_cpu_freeze, NULL);
>  				break;
>  #endif
> +
> +			      case IPI_FLUSH_TLB:
> +			      {
> +				extern unsigned long flush_start, flush_end, flush_nbits, flush_rid;
> +				extern atomic_t flush_cpu_count;
> +				unsigned long saved_rid = ia64_get_rr(flush_start);
> +				unsigned long end = flush_end;
> +				unsigned long start = flush_start;
> +				unsigned long nbits = flush_nbits;
> +	
> +				/*
> +				 * Current CPU may be running with different RID so we need to
> +				 * reload the RID of flushed address.  Purging the translation
> +				 * also needs ALAT invalidation; we do not need "invala" here
> +				 * since it is done in ia64_leave_kernel.
> +				 */
> +				ia64_srlz_d();
> +				if (saved_rid != flush_rid) {
> +					ia64_set_rr(flush_start, flush_rid);
> +					ia64_srlz_d();
> +				}
> +
> +				do {
> +					/*
> +					 * Purge local TLB entries.
> +				 	 */
> +					__asm__ __volatile__ ("ptc.l %0,%1" ::
> +							      "r"(start), "r"(nbits<<2) : "memory");
> +					start += (1UL << nbits);
> +				} while (start < end);
> +
> +				ia64_barrier();
> +				ia64_srlz_i();			/* srlz.i implies srlz.d */
> +
> +				if (saved_rid != flush_rid) {
> +					ia64_set_rr(flush_start, saved_rid);
> +					ia64_srlz_d();
> +				}
> +				atomic_dec(&flush_cpu_count);
> +				break;
> +			      }
>  			      default:
>  				printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);
>  				break;
> @@ -317,6 +359,13 @@ smp_flush_tlb_cpumask(cpumask_t xcpumask
>  }
>  
>  void
> +smp_send_flush_tlb (void)
> +{
> +	send_IPI_allbutself(IPI_FLUSH_TLB);
> +}
> +
> +
> +void
>  smp_flush_tlb_all (void)
>  {
>  	on_each_cpu((void (*)(void *))local_flush_tlb_all, NULL, 1, 1);
> _
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,
	Beside coding style issue, there are race conditions in this patch. You
should reconsider the design.
	Please consider the scenario when many cpus are calling
ia64_global_tlb_purge at the same time without any lock.
	Using global variables to indicate tlb flush start and end is not safe
here.	

Thanks
Zou Nan hai

RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to bedisabled

[Luck, Tony]

> Please consider the scenario when many cpus are calling
> ia64_global_tlb_purge at the same time without any lock.
> Using global variables to indicate tlb flush start and end is not safe
> here.	

Isn't everything protected by the

	spin_lock(&ptcg_lock);
	 ...
	spin_unlock(&ptcg_lock);

in ia64_global_tlb_purge()?  Though the comment that this lock
is required for HW serialization would need to be updated to
note that the s/w implementation also requires this serialization.

-Tony

RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to

[Zou Nan hai]

On Fri, 2007-08-31 at 09:45, Luck, Tony wrote:
> > Please consider the scenario when many cpus are calling
> > ia64_global_tlb_purge at the same time without any lock.
> > Using global variables to indicate tlb flush start and end is not safe
> > here.	
> 
> Isn't everything protected by the
> 
> 	spin_lock(&ptcg_lock);
> 	 ...
> 	spin_unlock(&ptcg_lock);
> 
> in ia64_global_tlb_purge()?  Though the comment that this lock
> is required for HW serialization would need to be updated to
> note that the s/w implementation also requires this serialization.
> 
> -Tony

Ah Yes, I missed this line when reading the patch...

So my comments would be
1. avoid declare global variables and functions in .c file. 
2. use more precise name for global variable.to e.g 
   ia64_global_tlb_flush_start is better than flush_start.
3. do not use asm in .c file, use intrins instead.

Thanks
Zou Nan hai


	

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to bedisabled

[Natalie Protasevich]

On 31 Aug 2007 09:48:07 +0800, Zou Nan hai <nanhai.zou@intel.com> wrote:
> On Fri, 2007-08-31 at 09:45, Luck, Tony wrote:
> > > Please consider the scenario when many cpus are calling
> > > ia64_global_tlb_purge at the same time without any lock.
> > > Using global variables to indicate tlb flush start and end is not safe
> > > here.
> >
> > Isn't everything protected by the
> >
> >       spin_lock(&ptcg_lock);
> >        ...
> >       spin_unlock(&ptcg_lock);
> >
> > in ia64_global_tlb_purge()?  Though the comment that this lock
> > is required for HW serialization would need to be updated to
> > note that the s/w implementation also requires this serialization.
> >
> > -Tony
>
> Ah Yes, I missed this line when reading the patch...
>
> So my comments would be
> 1. avoid declare global variables and functions in .c file.
> 2. use more precise name for global variable.to e.g
>    ia64_global_tlb_flush_start is better than flush_start.
> 3. do not use asm in .c file, use intrins instead.
>
Tony and Zou Nan hai,
Thank you very much for the review.
I am going to re-send the patch, with all the corrections except I
can't really see a good way to accommodate #1. Let me know if you have
specific suggestions on this.
Keith - I really tried to make it not to wrap, hope it will work this time.
Regards,
--Natalie

[PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Natalie Protasevich]

From: Natalie Protasevich <protasnb@gmail.com>

This patch allows to disable ptc.g. The code used to be in the kernel, then was removed 
in 2.4 since the bug that it was fixing has gone away. However, some large system vendors 
now want this capability available through a means that can be controlled by the platform 
in the event that there is an issue with either processor or their chipset where global 
ptc.g is not operational.  They want the mechanism for future platforms to work around 
such issues. It is also needed for platform makers when they deliberately do not use the 
global cache purge in their chipset implementation. (For such cases, Intel provided a SAL 
table entry to specify if ptc.g is allowed and how many).

---

  arch/ia64/kernel/smp.c |   50 +++++++++++++++++++++++++++++
  arch/ia64/mm/tlb.c     |   84 +++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 132 insertions(+), 2 deletions(-)

diff -puN arch/ia64/mm/tlb.c~ptcg arch/ia64/mm/tlb.c
--- linux-2.6.23-rc5/arch/ia64/mm/tlb.c~ptcg	2007-09-02 23:58:54.000000000 -0700
+++ linux-2.6.23-rc5-nataliep/arch/ia64/mm/tlb.c	2007-09-03 00:48:31.000000000 -0700
@@ -18,6 +18,7 @@
 #include <linux/smp.h>
 #include <linux/mm.h>
 #include <linux/bootmem.h>
+#include <linux/irq.h>
 
 #include <asm/delay.h>
 #include <asm/mmu_context.h>
@@ -83,6 +84,77 @@ wrap_mmu_context (struct mm_struct *mm)
 	local_flush_tlb_all();
 }
 
+unsigned long ia64_global_tlb_flush_end, ia64_global_tlb_flush_start,	
+              ia64_global_tlb_flush_nbits, ia64_global_tlb_flush_rid;
+atomic_t ia64_global_tlb_flush_cpu_count;
+
+static int noptcg;
+
+static int __init 
+noptcg_setup(char *str)
+{
+	noptcg = 1;
+	return 1;
+}
+__setup("noptcg", noptcg_setup);
+
+/*
+ * flush_tlb_no_ptcg is called with ptcg_lock locked
+ */
+static inline void
+flush_tlb_no_ptcg (unsigned long start, unsigned long end,
+		    unsigned long nbits)
+{
+	extern void smp_send_flush_tlb (void);
+	unsigned long saved_tpr = 0;
+	unsigned long flags;
+	int cpus = num_online_cpus();
+
+	/*
+	 * Sometimes this is called with interrupts disabled and causes
+	 * deadlock; to avoid this we enable interrupt and raise the TPR
+	 * to enable ONLY IPI.
+	 */
+	local_save_flags(flags);
+	if (!(flags & IA64_PSR_I)) {
+		saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
+		ia64_srlz_d();
+		ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
+		ia64_srlz_d();
+		local_irq_enable();
+	}
+
+	ia64_global_tlb_flush_rid = ia64_get_rr(start);
+	ia64_srlz_d();
+	ia64_global_tlb_flush_start = start;
+	ia64_global_tlb_flush_end = end;
+	ia64_global_tlb_flush_nbits = nbits;
+	atomic_set(&ia64_global_tlb_flush_cpu_count, cpus - 1);
+	smp_send_flush_tlb();
+	/*
+	 * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
+	 */
+	do {
+		ia64_ptcl(start, nbits<<2);
+		start += (1UL << nbits);
+	} while (start < end);
+
+	ia64_srlz_i();			/* srlz.i implies srlz.d */
+
+	/*
+	 * Wait for other CPUs to finish purging entries.
+	 */
+	while (atomic_read(&ia64_global_tlb_flush_cpu_count)) {
+		/* Nothing */
+	}
+
+	if (!(flags & IA64_PSR_I)) {
+		local_irq_disable();
+	 	ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
+		ia64_srlz_d();
+	}
+}
+
 void
 ia64_global_tlb_purge (struct mm_struct *mm, unsigned long start,
 		       unsigned long end, unsigned long nbits)
@@ -94,9 +166,17 @@ ia64_global_tlb_purge (struct mm_struct 
 		return;
 	}
 
-	/* HW requires global serialization of ptc.ga.  */
+	/* 
+	 * HW requires global serialization of ptc.ga, and same does
+	 * IPI based implementation of global TLB purge
+	 */
 	spin_lock(&ptcg_lock);
-	{
+	if (noptcg) {
+		/*
+		 * Handle the case when ptc.ga is not available in HW
+		 */
+		flush_tlb_no_ptcg(start, end, nbits);
+	} else {
 		do {
 			/*
 			 * Flush ALAT entries also.
diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
--- linux-2.6.23-rc5/arch/ia64/kernel/smp.c~ptcg	2007-09-02 23:58:54.000000000 -0700
+++ linux-2.6.23-rc5-nataliep/arch/ia64/kernel/smp.c	2007-09-02 23:59:25.000000000 -0700
@@ -79,6 +79,7 @@ static volatile struct call_data_struct 
 
 #define IPI_CALL_FUNC		0
 #define IPI_CPU_STOP		1
+#define IPI_FLUSH_TLB		2
 #define IPI_KDUMP_CPU_STOP	3
 
 /* This needs to be cacheline aligned because it is written to by *other* CPUs.  */
@@ -174,6 +175,48 @@ handle_IPI (int irq, void *dev_id)
 				unw_init_running(kdump_cpu_freeze, NULL);
 				break;
 #endif
+
+			      case IPI_FLUSH_TLB:
+			      {
+				extern unsigned long ia64_global_tlb_flush_start, 
+				       ia64_global_tlb_flush_end, ia64_global_tlb_flush_nbits, 
+				       ia64_global_tlb_flush_rid;
+				extern atomic_t ia64_global_tlb_flush_cpu_count;
+				unsigned long saved_rid = ia64_get_rr(ia64_global_tlb_flush_start);
+				unsigned long end = ia64_global_tlb_flush_end;
+				unsigned long start = ia64_global_tlb_flush_start;
+				unsigned long nbits = ia64_global_tlb_flush_nbits;
+	
+				/*
+				 * Current CPU may be running with different RID so we need to
+				 * reload the RID of flushed address.  Purging the translation
+				 * also needs ALAT invalidation; we do not need "invala" here
+				 * since it is done in ia64_leave_kernel.
+				 */
+				ia64_srlz_d();
+				if (saved_rid != ia64_global_tlb_flush_rid) {
+					ia64_set_rr(ia64_global_tlb_flush_start, ia64_global_tlb_flush_rid);
+					ia64_srlz_d();
+				}
+
+				do {
+					/*
+					 * Purge local TLB entries.
+				 	 */
+					ia64_ptcl(start, nbits<<2);
+					start += (1UL << nbits);
+				} while (start < end);
+
+				ia64_barrier();
+				ia64_srlz_i();			/* srlz.i implies srlz.d */
+
+				if (saved_rid != ia64_global_tlb_flush_rid) {
+					ia64_set_rr(ia64_global_tlb_flush_start, saved_rid);
+					ia64_srlz_d();
+				}
+				atomic_dec(&ia64_global_tlb_flush_cpu_count);
+				break;
+			      }
 			      default:
 				printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);
 				break;
@@ -317,6 +360,13 @@ smp_flush_tlb_cpumask(cpumask_t xcpumask
 }
 
 void
+smp_send_flush_tlb (void)
+{
+	send_IPI_allbutself(IPI_FLUSH_TLB);
+}
+
+
+void
 smp_flush_tlb_all (void)
 {
 	on_each_cpu((void (*)(void *))local_flush_tlb_all, NULL, 1, 1);
_

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Jes Sorensen]

>>>>> "Natalie" = Natalie Protasevich <protasnb@gmail.com> writes:

Natalie> From: Natalie Protasevich <protasnb@gmail.com>

Natalie> This patch allows to disable ptc.g. The code used to be in
Natalie> the kernel, then was removed in 2.4 since the bug that it was
Natalie> fixing has gone away. However, some large system vendors now
Natalie> want this capability available through a means that can be
Natalie> controlled by the platform in the event that there is an
Natalie> issue with either processor or their chipset where global
Natalie> ptc.g is not operational.  They want the mechanism for future
Natalie> platforms to work around such issues. It is also needed for
Natalie> platform makers when they deliberately do not use the global
Natalie> cache purge in their chipset implementation. (For such cases,
Natalie> Intel provided a SAL table entry to specify if ptc.g is
Natalie> allowed and how many).

If you need a special TLB purge implementation, please use the machine
vector as we do on the sn2 architecture - there is no reason to
implement a boot time option for this.

Who are these large system vendors who want this patch in? I presume
it's not the people running gmail? :-)

Cheers,
Jes

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Jes Sorensen]

> From: Natalie Protasevich <protasnb@gmail.com>

> This patch allows to disable ptc.g. The code used to be in the
> kernel, then was removed in 2.4 since the bug that it was fixing has
> gone away. However, some large system vendors now want this
> capability available through a means that can be controlled by the
> platform in the event that there is an issue with either processor
> or their chipset where global ptc.g is not operational.  They want
> the mechanism for future platforms to work around such issues. It
> is also needed for platform makers when they deliberately do not
> use the global cache purge in their chipset implementation. (For
> such cases, Intel provided a SAL table entry to specify if ptc.g is
> allowed and how many).

Hi Natalie,

I still don't understand the need for this patch given my comment to
your last posting and I'd like to know what the actual usage scenario
is.

That said, a few comments on the coding style and patch submission
below. Please make sure to read Documentation/CodingStyle and
Documentation/SubmittingPatches

1) No Signed-off-by: line.
---

+/*
+ * flush_tlb_no_ptcg is called with ptcg_lock locked
+ */
+static inline void
+flush_tlb_no_ptcg (unsigned long start, unsigned long end,
+		    unsigned long nbits)
+{
+	extern void smp_send_flush_tlb (void);

Ewwwwwwwww! prototypes within the function :-(

+	atomic_set(&ia64_global_tlb_flush_cpu_count, cpus - 1);
+	smp_send_flush_tlb();
+	/*
+	 * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
+	 */

A column is 80 characters, max.

@@ -94,9 +166,17 @@ ia64_global_tlb_purge (struct mm_struct 
 		return;
 	}
 
-	/* HW requires global serialization of ptc.ga.  */
+	/* 
+	 * HW requires global serialization of ptc.ga, and same does
+	 * IPI based implementation of global TLB purge
+	 */
 	spin_lock(&ptcg_lock);
-	{
+	if (noptcg) {
+		/*
+		 * Handle the case when ptc.ga is not available in HW
+		 */
+		flush_tlb_no_ptcg(start, end, nbits);
+	} else {

This just underlines why this should be implemented via the machine
vectors.

diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
--- linux-2.6.23-rc5/arch/ia64/kernel/smp.c~ptcg	2007-09-02 23:58:54.000000000 -0700
+++ linux-2.6.23-rc5-nataliep/arch/ia64/kernel/smp.c	2007-09-02 23:59:25.000000000 -0700
@@ -79,6 +79,7 @@ static volatile struct call_data_struct 
 
 #define IPI_CALL_FUNC		0
 #define IPI_CPU_STOP		1
+#define IPI_FLUSH_TLB		2
 #define IPI_KDUMP_CPU_STOP	3
 
 /* This needs to be cacheline aligned because it is written to by *other* CPUs.  */

@@ -174,6 +175,48 @@ handle_IPI (int irq, void *dev_id)
 				unw_init_running(kdump_cpu_freeze, NULL);
 				break;
 #endif
+
+			      case IPI_FLUSH_TLB:
+			      {
+				extern unsigned long ia64_global_tlb_flush_start, 
+				       ia64_global_tlb_flush_end, ia64_global_tlb_flush_nbits, 
+				       ia64_global_tlb_flush_rid;
+				extern atomic_t ia64_global_tlb_flush_cpu_count;

Please, no external prototypes hidden within the function!

Indents are 8 chars - but if you put the extern's in the place where
they belond you won't need the brackets here in the first place.

+				unsigned long saved_rid = ia64_get_rr(ia64_global_tlb_flush_start);
+				unsigned long end = ia64_global_tlb_flush_end;
+				unsigned long start = ia64_global_tlb_flush_start;
+				unsigned long nbits = ia64_global_tlb_flush_nbits;

Again, stick to 80 characters.

+	

Gratitious whitespace.

+				/*
+				 * Current CPU may be running with different RID so we need to
+				 * reload the RID of flushed address.  Purging the translation
+				 * also needs ALAT invalidation; we do not need "invala" here
+				 * since it is done in ia64_leave_kernel.
+				 */

More 80 character problems.

+				ia64_srlz_d();
+				if (saved_rid != ia64_global_tlb_flush_rid) {
+					ia64_set_rr(ia64_global_tlb_flush_start, ia64_global_tlb_flush_rid);

Ditto

+				if (saved_rid != ia64_global_tlb_flush_rid) {
+					ia64_set_rr(ia64_global_tlb_flush_start, saved_rid);

And again....

+					ia64_srlz_d();
+				}
+				atomic_dec(&ia64_global_tlb_flush_cpu_count);
+				break;
+			      }
 			      default:
 				printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);

And again....

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Robin Holt]

Please don't take this as a review.  I only glanced over it while waiting
for coffee to brew.

How does this align with sn2's tlb shootdown mechanism?  It seems similar
in intent.


On Mon, Sep 03, 2007 at 01:06:20AM -0700, Natalie Protasevich wrote:
> global cache purge in their chipset implementation. (For such cases, Intel provided a SAL 
> table entry to specify if ptc.g is allowed and how many).

This seems odd.  You never use that sal call to initialized noptcg.
Is that an oversight?

> +	/*
> +	 * Wait for other CPUs to finish purging entries.
> +	 */
> +	while (atomic_read(&ia64_global_tlb_flush_cpu_count)) {
> +		/* Nothing */

I think you want a cpu_relax() for hyper-threaded cpus can make
progress.

> -	/* HW requires global serialization of ptc.ga.  */
> +	/* 
> +	 * HW requires global serialization of ptc.ga, and same does
> +	 * IPI based implementation of global TLB purge

How about:
	 * HW requires global serialization of ptc operations */

RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Luck, Tony]

>> global cache purge in their chipset implementation. (For such cases, Intel provided a SAL 
>> table entry to specify if ptc.g is allowed and how many).
>
> This seems odd.  You never use that sal call to initialized noptcg.
> Is that an oversight?

The mechanism is a SAL table entry, not a SAL call.  Currently that
entry provides no mechanism to specify that ptc.g should not be used
at all (the entry provides the count of how many ptc.g can happen in
parallel, but the spec says that the value "0" means "1" :-( )

There is an ongoing discussion with DIG64 to use a currently reserved
field in the table to specify the value "0".  If that change is approved,
then we can add code to enable Natalie's code based on the SAL table.

-Tony

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Natalie Protasevich]

On 9/4/07, Luck, Tony <tony.luck@intel.com> wrote:
> >> global cache purge in their chipset implementation. (For such cases, Intel provided a SAL
> >> table entry to specify if ptc.g is allowed and how many).
> >
> > This seems odd.  You never use that sal call to initialized noptcg.
> > Is that an oversight?
>
> The mechanism is a SAL table entry, not a SAL call.  Currently that
> entry provides no mechanism to specify that ptc.g should not be used
> at all (the entry provides the count of how many ptc.g can happen in
> parallel, but the spec says that the value "0" means "1" :-( )
>
> There is an ongoing discussion with DIG64 to use a currently reserved
> field in the table to specify the value "0".  If that change is approved,
> then we can add code to enable Natalie's code based on the SAL table.
>
> -Tony
>

Yes, as Tony said this is a provision for the (near) future when the
actual mechanism of how the ptc.g availability to be shown in the bios
will be decided on. Then the boot option will be removed. The code is
already urgently needed for current platform work by aforementioned
companies :)
Jes, thank - I will go through your remarks thoroughly, yours and
Robin's, and will fight the wrapping thing to the end...
Regards,
--Natalie

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

On 03 Sep 2007 05:21:41 -0400, Jes Sorensen <jes@sgi.com> wrote:
> >>>>> "Natalie" = Natalie Protasevich <protasnb@gmail.com> writes:
>
> Natalie> From: Natalie Protasevich <protasnb@gmail.com>
>
> Natalie> This patch allows to disable ptc.g. The code used to be in
> Natalie> the kernel, then was removed in 2.4 since the bug that it was
> Natalie> fixing has gone away. However, some large system vendors now
> Natalie> want this capability available through a means that can be
> Natalie> controlled by the platform in the event that there is an
> Natalie> issue with either processor or their chipset where global
> Natalie> ptc.g is not operational.  They want the mechanism for future
> Natalie> platforms to work around such issues. It is also needed for
> Natalie> platform makers when they deliberately do not use the global
> Natalie> cache purge in their chipset implementation. (For such cases,
> Natalie> Intel provided a SAL table entry to specify if ptc.g is
> Natalie> allowed and how many).
>
> If you need a special TLB purge implementation, please use the machine
> vector as we do on the sn2 architecture - there is no reason to
> implement a boot time option for this.

The boot option is only temporary, until the SAL/PAL mechanism will be
shaken up.
I will digest and use the machvec then, how about that? For now I'd
like to provide this revived patch as is  for it is proven to be
working in the past, if you don't mind this first stage.

> Who are these large system vendors who want this patch in? I presume
> it's not the people running gmail? :-)

No :) those interested are big hardware makers of large scaled out
boxes, such as HP, UIS. They are using own asics and are not
necessarily being able to keep chipset native capabilities intact. As
I said in the preamble, the mechanism has to be there so they can turn
the ptc.g off and run the OS.
Regards,
--Natalie
>
> Cheers,
> Jes
>

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Bjorn Helgaas]

On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote:
> This patch allows to disable ptc.g. The code used to be in the kernel, then was removed 
> in 2.4 since the bug that it was fixing has gone away. However, some large system vendors 
> now want this capability available through a means that can be controlled by the platform 
> in the event that there is an issue with either processor or their chipset where global 
> ptc.g is not operational.  They want the mechanism for future platforms to work around 
> such issues. It is also needed for platform makers when they deliberately do not use the 
> global cache purge in their chipset implementation. (For such cases, Intel provided a SAL 
> table entry to specify if ptc.g is allowed and how many).

This is an area prone to hard-to-reproduce and hard-to-debug problems,
and there's a lot of subtle stuff in this patch.  So I worry about the
fact that we're adding a noptcg path that will be basically untested,
compared with the normal path.

> +static inline void
> +flush_tlb_no_ptcg (unsigned long start, unsigned long end,
> +		    unsigned long nbits)
> +{
> +	extern void smp_send_flush_tlb (void);
> +	unsigned long saved_tpr = 0;
> +	unsigned long flags;
> +	int cpus = num_online_cpus();

This isn't safe with respect to CPU hotplug, is it?  What if a CPU
goes offline between here and the "wait for other CPUs" loop below?

> +	/*
> +	 * Sometimes this is called with interrupts disabled and causes
> +	 * deadlock; to avoid this we enable interrupt and raise the TPR
> +	 * to enable ONLY IPI.
> +	 */

I don't think the comment matches the code.  With TPR, you can mask
interrupts 0x10-0x1f, 0x10-0x2f, 0x10-0x3f, ..., 0x10-0xef, or 0x10-0xff.
So you have to leave at least interrupts 0xf0-0xff unmasked, which
includes IA64_IPI_VECTOR at 0xfe and 15 others.

> +	local_save_flags(flags);
> +	if (!(flags & IA64_PSR_I)) {
> +		saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
> +		ia64_srlz_d();

Why is this srlz.d needed?

> +		ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);

This just writes back the same value we read above.  It doesn't really
do anything, does it?

> +		ia64_srlz_d();
> +		local_irq_enable();
> +	}
> +
> +	ia64_global_tlb_flush_rid = ia64_get_rr(start);
> +	ia64_srlz_d();

Why is this srlz.d needed?

> +	ia64_global_tlb_flush_start = start;
> +	ia64_global_tlb_flush_end = end;
> +	ia64_global_tlb_flush_nbits = nbits;
> +	atomic_set(&ia64_global_tlb_flush_cpu_count, cpus - 1);
> +	smp_send_flush_tlb();
> +	/*
> +	 * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
> +	 */
> +	do {
> +		ia64_ptcl(start, nbits<<2);
> +		start += (1UL << nbits);
> +	} while (start < end);
> +
> +	ia64_srlz_i();			/* srlz.i implies srlz.d */
> +
> +	/*
> +	 * Wait for other CPUs to finish purging entries.
> +	 */
> +	while (atomic_read(&ia64_global_tlb_flush_cpu_count)) {
> +		/* Nothing */
> +	}
> +
> +	if (!(flags & IA64_PSR_I)) {
> +		local_irq_disable();
> +	 	ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
> +		ia64_srlz_d();
> +	}
> +}
> +
>  void
>  ia64_global_tlb_purge (struct mm_struct *mm, unsigned long start,
>  		       unsigned long end, unsigned long nbits)
> diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
> --- linux-2.6.23-rc5/arch/ia64/kernel/smp.c~ptcg	2007-09-02 23:58:54.000000000 -0700
> +++ linux-2.6.23-rc5-nataliep/arch/ia64/kernel/smp.c	2007-09-02 23:59:25.000000000 -0700
> @@ -174,6 +175,48 @@ handle_IPI (int irq, void *dev_id)
>  				unw_init_running(kdump_cpu_freeze, NULL);
>  				break;
>  #endif
> +
> +			      case IPI_FLUSH_TLB:
> +			      {
> +				extern unsigned long ia64_global_tlb_flush_start, 
> +				       ia64_global_tlb_flush_end, ia64_global_tlb_flush_nbits, 
> +				       ia64_global_tlb_flush_rid;
> +				extern atomic_t ia64_global_tlb_flush_cpu_count;
> +				unsigned long saved_rid = ia64_get_rr(ia64_global_tlb_flush_start);
> +				unsigned long end = ia64_global_tlb_flush_end;
> +				unsigned long start = ia64_global_tlb_flush_start;
> +				unsigned long nbits = ia64_global_tlb_flush_nbits;
> +	
> +				/*
> +				 * Current CPU may be running with different RID so we need to
> +				 * reload the RID of flushed address.  Purging the translation
> +				 * also needs ALAT invalidation; we do not need "invala" here
> +				 * since it is done in ia64_leave_kernel.
> +				 */
> +				ia64_srlz_d();

Why is this srlz.d needed?

> +				if (saved_rid != ia64_global_tlb_flush_rid) {
> +					ia64_set_rr(ia64_global_tlb_flush_start, ia64_global_tlb_flush_rid);
> +					ia64_srlz_d();
> +				}
> +
> +				do {
> +					/*
> +					 * Purge local TLB entries.
> +				 	 */
> +					ia64_ptcl(start, nbits<<2);
> +					start += (1UL << nbits);
> +				} while (start < end);
> +
> +				ia64_barrier();
> +				ia64_srlz_i();			/* srlz.i implies srlz.d */

Why are these (barrier & srlz.i) needed?

> +				if (saved_rid != ia64_global_tlb_flush_rid) {
> +					ia64_set_rr(ia64_global_tlb_flush_start, saved_rid);
> +					ia64_srlz_d();
> +				}
> +				atomic_dec(&ia64_global_tlb_flush_cpu_count);
> +				break;
> +			      }
>  			      default:
>  				printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);
>  				break;

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled - take 2

[Natalie Protasevich]

On 9/4/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Monday 03 September 2007 02:06:20 am Natalie Protasevich wrote:
> > This patch allows to disable ptc.g. The code used to be in the kernel, then was removed
> > in 2.4 since the bug that it was fixing has gone away. However, some large system vendors
> > now want this capability available through a means that can be controlled by the platform
> > in the event that there is an issue with either processor or their chipset where global
> > ptc.g is not operational.  They want the mechanism for future platforms to work around
> > such issues. It is also needed for platform makers when they deliberately do not use the
> > global cache purge in their chipset implementation. (For such cases, Intel provided a SAL
> > table entry to specify if ptc.g is allowed and how many).
>
> This is an area prone to hard-to-reproduce and hard-to-debug problems,
> and there's a lot of subtle stuff in this patch.  So I worry about the
> fact that we're adding a noptcg path that will be basically untested,
> compared with the normal path.

I tested it on the tiger before submitting it, so it boots and runs.

>
> > +static inline void
> > +flush_tlb_no_ptcg (unsigned long start, unsigned long end,
> > +                 unsigned long nbits)
> > +{
> > +     extern void smp_send_flush_tlb (void);
> > +     unsigned long saved_tpr = 0;
> > +     unsigned long flags;
> > +     int cpus = num_online_cpus();
>
> This isn't safe with respect to CPU hotplug, is it?  What if a CPU
> goes offline between here and the "wait for other CPUs" loop below?

I will test it with hot plug, good point.

>
> > +     /*
> > +      * Sometimes this is called with interrupts disabled and causes
> > +      * deadlock; to avoid this we enable interrupt and raise the TPR
> > +      * to enable ONLY IPI.
> > +      */
>
> I don't think the comment matches the code.  With TPR, you can mask
> interrupts 0x10-0x1f, 0x10-0x2f, 0x10-0x3f, ..., 0x10-0xef, or 0x10-0xff.
> So you have to leave at least interrupts 0xf0-0xff unmasked, which
> includes IA64_IPI_VECTOR at 0xfe and 15 others.

Hmm, I only see IA64_MCA_WAKEUP_VECTOR and few kinds of IPI above
0xf0. Are those potential ones that you mean?
>
> > +     local_save_flags(flags);
> > +     if (!(flags & IA64_PSR_I)) {
> > +             saved_tpr = ia64_getreg(_IA64_REG_CR_TPR);
> > +             ia64_srlz_d();
>
> Why is this srlz.d needed?
>
> > +             ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
>
> This just writes back the same value we read above.  It doesn't really
> do anything, does it?

To answer the above two questions I have to look up how TPR works,
can't argue with original code. Maybe Tony or Zou Nan hai can comment
on this.
Same applies to all the following serialization questions. I will do
some research if Intel people won't beat me to answer those (hope they
will :)
Thanks,
--Natalie

>
> > +             ia64_srlz_d();
> > +             local_irq_enable();
> > +     }
> > +
> > +     ia64_global_tlb_flush_rid = ia64_get_rr(start);
> > +     ia64_srlz_d();
>
> Why is this srlz.d needed?

>
> > +     ia64_global_tlb_flush_start = start;
> > +     ia64_global_tlb_flush_end = end;
> > +     ia64_global_tlb_flush_nbits = nbits;
> > +     atomic_set(&ia64_global_tlb_flush_cpu_count, cpus - 1);
> > +     smp_send_flush_tlb();
> > +     /*
> > +      * Purge local TLB entries. ALAT invalidation is done in ia64_leave_kernel.
> > +      */
> > +     do {
> > +             ia64_ptcl(start, nbits<<2);
> > +             start += (1UL << nbits);
> > +     } while (start < end);
> > +
> > +     ia64_srlz_i();                  /* srlz.i implies srlz.d */
> > +
> > +     /*
> > +      * Wait for other CPUs to finish purging entries.
> > +      */
> > +     while (atomic_read(&ia64_global_tlb_flush_cpu_count)) {
> > +             /* Nothing */
> > +     }
> > +
> > +     if (!(flags & IA64_PSR_I)) {
> > +             local_irq_disable();
> > +             ia64_setreg(_IA64_REG_CR_TPR, saved_tpr);
> > +             ia64_srlz_d();
> > +     }
> > +}
> > +
> >  void
> >  ia64_global_tlb_purge (struct mm_struct *mm, unsigned long start,
> >                      unsigned long end, unsigned long nbits)
> > diff -puN arch/ia64/kernel/smp.c~ptcg arch/ia64/kernel/smp.c
> > --- linux-2.6.23-rc5/arch/ia64/kernel/smp.c~ptcg      2007-09-02 23:58:54.000000000 -0700
> > +++ linux-2.6.23-rc5-nataliep/arch/ia64/kernel/smp.c  2007-09-02 23:59:25.000000000 -0700
> > @@ -174,6 +175,48 @@ handle_IPI (int irq, void *dev_id)
> >                               unw_init_running(kdump_cpu_freeze, NULL);
> >                               break;
> >  #endif
> > +
> > +                           case IPI_FLUSH_TLB:
> > +                           {
> > +                             extern unsigned long ia64_global_tlb_flush_start,
> > +                                    ia64_global_tlb_flush_end, ia64_global_tlb_flush_nbits,
> > +                                    ia64_global_tlb_flush_rid;
> > +                             extern atomic_t ia64_global_tlb_flush_cpu_count;
> > +                             unsigned long saved_rid = ia64_get_rr(ia64_global_tlb_flush_start);
> > +                             unsigned long end = ia64_global_tlb_flush_end;
> > +                             unsigned long start = ia64_global_tlb_flush_start;
> > +                             unsigned long nbits = ia64_global_tlb_flush_nbits;
> > +
> > +                             /*
> > +                              * Current CPU may be running with different RID so we need to
> > +                              * reload the RID of flushed address.  Purging the translation
> > +                              * also needs ALAT invalidation; we do not need "invala" here
> > +                              * since it is done in ia64_leave_kernel.
> > +                              */
> > +                             ia64_srlz_d();
>
> Why is this srlz.d needed?
>
> > +                             if (saved_rid != ia64_global_tlb_flush_rid) {
> > +                                     ia64_set_rr(ia64_global_tlb_flush_start, ia64_global_tlb_flush_rid);
> > +                                     ia64_srlz_d();
> > +                             }
> > +
> > +                             do {
> > +                                     /*
> > +                                      * Purge local TLB entries.
> > +                                      */
> > +                                     ia64_ptcl(start, nbits<<2);
> > +                                     start += (1UL << nbits);
> > +                             } while (start < end);
> > +
> > +                             ia64_barrier();
> > +                             ia64_srlz_i();                  /* srlz.i implies srlz.d */
>
> Why are these (barrier & srlz.i) needed?
>
> > +                             if (saved_rid != ia64_global_tlb_flush_rid) {
> > +                                     ia64_set_rr(ia64_global_tlb_flush_start, saved_rid);
> > +                                     ia64_srlz_d();
> > +                             }
> > +                             atomic_dec(&ia64_global_tlb_flush_cpu_count);
> > +                             break;
> > +                           }
> >                             default:
> >                               printk(KERN_CRIT "Unknown IPI on CPU %d: %lu\n", this_cpu, which);
> >                               break;
>

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be

[Jes Sorensen]

Natalie Protasevich wrote:
> On 03 Sep 2007 05:21:41 -0400, Jes Sorensen <jes@sgi.com> wrote:
> The boot option is only temporary, until the SAL/PAL mechanism will be
> shaken up.
> I will digest and use the machvec then, how about that? For now I'd
> like to provide this revived patch as is  for it is proven to be
> working in the past, if you don't mind this first stage.

Hi Natalie,

If the boot option is meant as a temporary measure, then I am game for
it. However I still think it's better to make the boot option decide on
a machine vector rather than doing this as a hack the way it is now.
How about a machvec=dignoptcg option instead? That way once the SAL
interface becomes available, you simply make the SAL call and pick the
machine vector based on that.

>> Who are these large system vendors who want this patch in? I presume
>> it's not the people running gmail? :-)
> 
> No :) those interested are big hardware makers of large scaled out
> boxes, such as HP, UIS. They are using own asics and are not
> necessarily being able to keep chipset native capabilities intact. As
> I said in the preamble, the mechanism has to be there so they can turn
> the ptc.g off and run the OS.

But those vendors only make small boxes :-) SGI has had this isusue from
day one, but we have other things that are non standard too, which is
one of the reasons the machine vectors came into play in the first
place.

So IMHO I think the best solution would still be to introduce a new
machine vector - this will avoid adding code to the current
global_tlb_purge() function and allow you to do an optimized version for
the new systems too.

Cheers,
Jes

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Robin Holt]

> No :) those interested are big hardware makers of large scaled out
> boxes, such as HP, UIS. They are using own asics and are not
> necessarily being able to keep chipset native capabilities intact. As
> I said in the preamble, the mechanism has to be there so they can turn
> the ptc.g off and run the OS.

This really sounds like it is best done as a machvec.  Currently, Altix
(sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
mechanism which is very flexible and scalable.  Maybe it would be best
to follow that example.  To repeat Bjorn's comments, this area can be
fraught with _VERY_ difficult to diagnose problems.  A boot test can
hardly be expected to uncover all the races so be patient while we walk
through this code.

Thanks,
Robin

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

On 9/5/07, Robin Holt <holt@sgi.com> wrote:
> > No :) those interested are big hardware makers of large scaled out
> > boxes, such as HP, UIS. They are using own asics and are not
> > necessarily being able to keep chipset native capabilities intact. As
> > I said in the preamble, the mechanism has to be there so they can turn
> > the ptc.g off and run the OS.
>
> This really sounds like it is best done as a machvec.  Currently, Altix
> (sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
> mechanism which is very flexible and scalable.  Maybe it would be best
> to follow that example.  To repeat Bjorn's comments, this area can be
> fraught with _VERY_ difficult to diagnose problems.  A boot test can
> hardly be expected to uncover all the races so be patient while we walk
> through this code.
>
All right, all right ... :) I'll do the machvec then. Thanks guys,
will peek into the sn2 to get an idea.

Regards,
--Natalie

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[David Mosberger-Tang]

In my opinion, machvec is a bad idea for a temporary workaround.
You'll need to create new header files etc etc all just for a
short-lived workaround.  Just my 2 cents.

  --david

On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> On 9/5/07, Robin Holt <holt@sgi.com> wrote:
> > > No :) those interested are big hardware makers of large scaled out
> > > boxes, such as HP, UIS. They are using own asics and are not
> > > necessarily being able to keep chipset native capabilities intact. As
> > > I said in the preamble, the mechanism has to be there so they can turn
> > > the ptc.g off and run the OS.
> >
> > This really sounds like it is best done as a machvec.  Currently, Altix
> > (sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
> > mechanism which is very flexible and scalable.  Maybe it would be best
> > to follow that example.  To repeat Bjorn's comments, this area can be
> > fraught with _VERY_ difficult to diagnose problems.  A boot test can
> > hardly be expected to uncover all the races so be patient while we walk
> > through this code.
> >
> All right, all right ... :) I'll do the machvec then. Thanks guys,
> will peek into the sn2 to get an idea.
>
> Regards,
> --Natalie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

On 9/5/07, David Mosberger-Tang <dmosberger@gmail.com> wrote:
> In my opinion, machvec is a bad idea for a temporary workaround.
> You'll need to create new header files etc etc all just for a
> short-lived workaround.  Just my 2 cents.
>
>   --david

This is actually a feature. Can be a workaround for platform that
didn't manage to make ptcg work, but can be intentionally disabled by
design. Big modular scaled out systems may choose to disable it
intentionally. I think it's more of feature implementation, which is
offered by architecture and has found some users, so I'd say this
might stay and not be short-lived. In this case, will machvec be more
appropriate?
Thanks,
--Natalie

>
> On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> > On 9/5/07, Robin Holt <holt@sgi.com> wrote:
> > > > No :) those interested are big hardware makers of large scaled out
> > > > boxes, such as HP, UIS. They are using own asics and are not
> > > > necessarily being able to keep chipset native capabilities intact. As
> > > > I said in the preamble, the mechanism has to be there so they can turn
> > > > the ptc.g off and run the OS.
> > >
> > > This really sounds like it is best done as a machvec.  Currently, Altix
> > > (sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
> > > mechanism which is very flexible and scalable.  Maybe it would be best
> > > to follow that example.  To repeat Bjorn's comments, this area can be
> > > fraught with _VERY_ difficult to diagnose problems.  A boot test can
> > > hardly be expected to uncover all the races so be patient while we walk
> > > through this code.
> > >
> > All right, all right ... :) I'll do the machvec then. Thanks guys,
> > will peek into the sn2 to get an idea.
> >
> > Regards,
> > --Natalie
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
>
> --
> Mosberger Consulting LLC, http://www.mosberger-consulting.com/
>

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[David Mosberger-Tang]

Natalie,

I'm confused.  In an earlier mail, you wrote:

 > The boot option is only temporary, until the SAL/PAL mechanism will be
 > shaken up.

Once the SAL/PAL mechanism exists, there won't be a need for
bootoption or a separate machvec anymore, or am I missing something?

The other thing that makes me a bit dubious about using a machvec here
is that it doesn't just apply for DIG, I'd think.  We wouldn't want to
duplicate all the existing machvecs (other than SGI, which never used
ptc.g anyhow), or would we?

  --david

On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> On 9/5/07, David Mosberger-Tang <dmosberger@gmail.com> wrote:
> > In my opinion, machvec is a bad idea for a temporary workaround.
> > You'll need to create new header files etc etc all just for a
> > short-lived workaround.  Just my 2 cents.
> >
> >   --david
>
> This is actually a feature. Can be a workaround for platform that
> didn't manage to make ptcg work, but can be intentionally disabled by
> design. Big modular scaled out systems may choose to disable it
> intentionally. I think it's more of feature implementation, which is
> offered by architecture and has found some users, so I'd say this
> might stay and not be short-lived. In this case, will machvec be more
> appropriate?
> Thanks,
> --Natalie
>
> >
> > On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> > > On 9/5/07, Robin Holt <holt@sgi.com> wrote:
> > > > > No :) those interested are big hardware makers of large scaled out
> > > > > boxes, such as HP, UIS. They are using own asics and are not
> > > > > necessarily being able to keep chipset native capabilities intact. As
> > > > > I said in the preamble, the mechanism has to be there so they can turn
> > > > > the ptc.g off and run the OS.
> > > >
> > > > This really sounds like it is best done as a machvec.  Currently, Altix
> > > > (sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
> > > > mechanism which is very flexible and scalable.  Maybe it would be best
> > > > to follow that example.  To repeat Bjorn's comments, this area can be
> > > > fraught with _VERY_ difficult to diagnose problems.  A boot test can
> > > > hardly be expected to uncover all the races so be patient while we walk
> > > > through this code.
> > > >
> > > All right, all right ... :) I'll do the machvec then. Thanks guys,
> > > will peek into the sn2 to get an idea.
> > >
> > > Regards,
> > > --Natalie
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> >
> >
> > --
> > Mosberger Consulting LLC, http://www.mosberger-consulting.com/
> >
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

On 9/6/07, David Mosberger-Tang <dmosberger@gmail.com> wrote:
> Natalie,
>
> I'm confused.  In an earlier mail, you wrote:
>
>  > The boot option is only temporary, until the SAL/PAL mechanism will be
>  > shaken up.
>
> Once the SAL/PAL mechanism exists, there won't be a need for
> bootoption or a separate machvec anymore, or am I missing something?

The SAL/PAL will only have information about ptc.g not being available
(like a flag). The OS has to have the code to handle this case which
is the IPI with subsequent local purge. The SAL/PAL mechanism only
releaves us from boot option, just like info in ACPI or SMBIOS would.
For now I just leave it to user input, until the mechanism will be
decided on. It's either mentioned above global tlb purge table entry
in SAL table, or alternative PALO (pal override) suggested by HP i
believe.

>
> The other thing that makes me a bit dubious about using a machvec here
> is that it doesn't just apply for DIG, I'd think.  We wouldn't want to
> duplicate all the existing machvecs (other than SGI, which never used
> ptc.g anyhow), or would we?
>
So far it appears to me that it will be defined for ia64 somewhere in
asm-generic/tlb.h and in asm-ia64/tlb.h as
platform_global_tlb_ipi_purge() something, but I'm not sure about
that, will have to start digging.
Thanks,
--Natalie
>   --david
>
> On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> > On 9/5/07, David Mosberger-Tang <dmosberger@gmail.com> wrote:
> > > In my opinion, machvec is a bad idea for a temporary workaround.
> > > You'll need to create new header files etc etc all just for a
> > > short-lived workaround.  Just my 2 cents.
> > >
> > >   --david
> >
> > This is actually a feature. Can be a workaround for platform that
> > didn't manage to make ptcg work, but can be intentionally disabled by
> > design. Big modular scaled out systems may choose to disable it
> > intentionally. I think it's more of feature implementation, which is
> > offered by architecture and has found some users, so I'd say this
> > might stay and not be short-lived. In this case, will machvec be more
> > appropriate?
> > Thanks,
> > --Natalie
> >
> > >
> > > On 9/5/07, Natalie Protasevich <protasnb@gmail.com> wrote:
> > > > On 9/5/07, Robin Holt <holt@sgi.com> wrote:
> > > > > > No :) those interested are big hardware makers of large scaled out
> > > > > > boxes, such as HP, UIS. They are using own asics and are not
> > > > > > necessarily being able to keep chipset native capabilities intact. As
> > > > > > I said in the preamble, the mechanism has to be there so they can turn
> > > > > > the ptc.g off and run the OS.
> > > > >
> > > > > This really sounds like it is best done as a machvec.  Currently, Altix
> > > > > (sn2) does not have a ptc.g that spans nodes.  We have our own tlb purge
> > > > > mechanism which is very flexible and scalable.  Maybe it would be best
> > > > > to follow that example.  To repeat Bjorn's comments, this area can be
> > > > > fraught with _VERY_ difficult to diagnose problems.  A boot test can
> > > > > hardly be expected to uncover all the races so be patient while we walk
> > > > > through this code.
> > > > >
> > > > All right, all right ... :) I'll do the machvec then. Thanks guys,
> > > > will peek into the sn2 to get an idea.
> > > >
> > > > Regards,
> > > > --Natalie
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > >
> > >
> > >
> > > --
> > > Mosberger Consulting LLC, http://www.mosberger-consulting.com/
> > >
> >
>
>
> --
> Mosberger Consulting LLC, http://www.mosberger-consulting.com/
>

RE: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Luck, Tony]

> So far it appears to me that it will be defined for ia64 somewhere in
> asm-generic/tlb.h and in asm-ia64/tlb.h as
> platform_global_tlb_ipi_purge() something, but I'm not sure about
> that, will have to start digging.

I'm voting with David on this one ... machvec doesn't look like
the right mechanism for this (all of the non-sn2 machvecs would
potentially have to be duplicated to provide ptc.g and !ptc.g
variants ... that doesn't sound like a good plan).

-Tony

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be

[Jes Sorensen]

Luck, Tony wrote:
>> So far it appears to me that it will be defined for ia64 somewhere in
>> asm-generic/tlb.h and in asm-ia64/tlb.h as
>> platform_global_tlb_ipi_purge() something, but I'm not sure about
>> that, will have to start digging.
> 
> I'm voting with David on this one ... machvec doesn't look like
> the right mechanism for this (all of the non-sn2 machvecs would
> potentially have to be duplicated to provide ptc.g and !ptc.g
> variants ... that doesn't sound like a good plan).

The reason why I suggested a machvec is to avoid cluttering up the
generic function with something like this. In addition I only see two
machvec's that may potentially get copied, the dig one and the hpzx1
one.

If we start adding clutter to the generic functions we will end up with
a 2-dimensional mesh of things where some is handled machvec style and
then we have local variations within the machvecs. I suspect the Unisys
and HP machines will end up having special machvecs for these machines
anyway.

Cheers,
Jes

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Bjorn Helgaas]

On Friday 07 September 2007 02:38:07 am Jes Sorensen wrote:
> The reason why I suggested a machvec is to avoid cluttering up the
> generic function with something like this. In addition I only see two
> machvec's that may potentially get copied, the dig one and the hpzx1
> one.
> 
> If we start adding clutter to the generic functions we will end up with
> a 2-dimensional mesh of things where some is handled machvec style and
> then we have local variations within the machvecs. I suspect the Unisys
> and HP machines will end up having special machvecs for these machines
> anyway.

I'm not aware of a current or planned HP machine where ptc.g will
not work.

Sometimes ptc.g doesn't work because of defects in early processor
or chipset prototypes, but I consider that a bring-up issue that is
not significant enough to warrant additional permanent code in the
kernel.

So I don't think we should have a special machvec for HP machines.

Bjorn

Re: [PATCH 1/1] Allow global purge traslation cache (ptc.g) to be disabled

[Natalie Protasevich]

On 9/7/07, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> On Friday 07 September 2007 02:38:07 am Jes Sorensen wrote:
> > The reason why I suggested a machvec is to avoid cluttering up the
> > generic function with something like this. In addition I only see two
> > machvec's that may potentially get copied, the dig one and the hpzx1
> > one.
> >
> > If we start adding clutter to the generic functions we will end up with
> > a 2-dimensional mesh of things where some is handled machvec style and
> > then we have local variations within the machvecs. I suspect the Unisys
> > and HP machines will end up having special machvecs for these machines
> > anyway.
>
> I'm not aware of a current or planned HP machine where ptc.g will
> not work.
>
> Sometimes ptc.g doesn't work because of defects in early processor
> or chipset prototypes, but I consider that a bring-up issue that is
> not significant enough to warrant additional permanent code in the
> kernel.
>
> So I don't think we should have a special machvec for HP machines.
>

I think this clears the issue, because for Unisys it's more of
bring-up problem also, which may  or may not end up being a permanent
feature. Therefore it doesn't mean that the workaround is temporary,
and shouldn't be kept around for future use. It was needed some while
ago, and is needed again. But it looks like machvec is not an option
then (oh well :)
Thanks,
--Natalie