From: Cliff Wickman <cpw@sgi.com>

TLB shootdown for SGI UV.

Depends on patch:
   x86-update-macros-used-by-uv-platform.patch   Jack Steiner May 29

This patch provides the ability to flush TLB's in cpu's that are not on
the local node.  The hardware mechanism for distributing the flush
messages is the UV's "broadcast assist unit".

The hook to intercept TLB shootdown requests is a 2-line change to
native_flush_tlb_others() (arch/x86/kernel/tlb_64.c).

This code has been tested on a hardware simulator. The real hardware
is not yet available.

The shootdown statistics are provided through /proc/sgi_uv/ptc_statistics.
The use of /sys was considered, but would have required the use of
many /sys files.  The debugfs was also considered, but these statistics
should be available on an ongoing basis, not just for debugging.

Issues to be fixed later:
- The IRQ for the messaging interrupt is currently hardcoded as 200
  (see UV_BAU_MESSAGE).  It should be dynamically assigned in the future.
- The use of appropriate udelay()'s is untested, as they are a problem
  in the simulator.

Diffed against 2.6.26-rc2-mm1

Signed-off-by: Cliff Wickman <cpw@sgi.com>
---
 arch/x86/kernel/Makefile    |    2 
 arch/x86/kernel/entry_64.S  |    4 
 arch/x86/kernel/tlb_64.c    |    5 
 arch/x86/kernel/tlb_uv.c    |  736 ++++++++++++++++++++++++++++++++++++++++++++
 include/asm-x86/uv/uv_bau.h |  331 +++++++++++++++++++
 5 files changed, 1077 insertions(+), 1 deletion(-)

Index: linux/arch/x86/kernel/entry_64.S
===================================================================
--- linux.orig/arch/x86/kernel/entry_64.S
+++ linux/arch/x86/kernel/entry_64.S
@@ -822,6 +822,10 @@ ENTRY(apic_timer_interrupt)
 	apicinterrupt LOCAL_TIMER_VECTOR,smp_apic_timer_interrupt
 END(apic_timer_interrupt)
 
+ENTRY(uv_bau_message_intr1)
+	apicinterrupt 220,uv_bau_message_interrupt
+END(uv_bau_message_intr1)
+
 ENTRY(error_interrupt)
 	apicinterrupt ERROR_APIC_VECTOR,smp_error_interrupt
 ...
[ message continues ]

looks mostly good to me, but there are a few code structure and 



'fw' is int here, while uv_write_local_mmr() takes 'unsigned long', so 
'fw' will be sign-extended. It's better to use the natural type of such 
values, even if you only fill in low bits. (otherwise it can later on 

use a:

		if (!(...))
			continue;

construct to make the function more readable and to save an indentation 
level. Possibly split the iterator body into a separate function as 



use such comment style:

 /*
  * Comment
  */


dont use ktime_get() in performance-sensitive code, it can get _really_ 
expensive if GTOD falls back to pmtimer or hpet or other southbridge-ish 



static variable in the middle of file - data should move up to the 
header portion of the file, or this functionality should go into a 

unnecessary line break. (applies to many other function definitions in 

static variable hidden in function. It should move into head of the file 


function way too large - per node initialization should go into a helper 


please use the style and alignment found in other areas of 
include/asm-x86, such as include/asm-x86/processor.h. (applies to other 

this (and the other atomic_*() additions) should go into atomic.h 

function prototypes in headers should use 'extern'.



	Ingo
--

[ message continues ]

i've created a new branch for this in -tip, you can find it in 
tip/x86/uv, under:

  http://people.redhat.com/mingo/tip.git/README

this new topic branch is based on tip/x86/irq and this is intended to be 
a temporary branch until these changes become mergable into tip/x86/irq 
[where for example the "x86, uv: update macros used by UV platform" 
commit lives]. Please send fix patches against this branch.

	Ingo
--

[ message continues ]

Ingo,

I've addressed all the issues that you raised, and I think made
some good structural improvements as a result.

Also, in moving my atomic asm's to atomic_64.h and testing them
further I uncovered problems that I then addressed.
I'm no guru on x86 asm's however, so an inspection of those is
probably a good idea.














no good reason.  was inherited from some sn2 code

done




done
 
-Cliff
--

[ message continues ]