All of lore.kernel.org
 help / color / mirror / Atom feed
From: R Sharada <sharada@in.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: akpm@osdl.org, torvalds@osdl.org, anton@samba.org,
	linux-kernel@vger.kernel.org, miltonm@bga.com
Subject: Re: [PATCH] ppc64: native hash clear
Date: Fri, 6 May 2005 18:11:58 +0530	[thread overview]
Message-ID: <20050506124158.GA2741@in.ibm.com> (raw)
In-Reply-To: <17019.3752.917407.742713@cargo.ozlabs.ibm.com>

Andrew, Paulus,
	There are 2 more patches for kexec ppc64. I did not see those two get
posted. 
	Request these patches to get merged into the next -mm.



Add code to clear the hash table and invalidate the tlb for native (SMP,
non-LPAR) mode.  Supports 16M and 4k pages.

Signed-off-by: Milton Miller <miltonm@bga.com>

Signed-off-by: R Sharada <sharada@in.ibm.com>
---

 linux-2.6.12-rc3-mm3-sharada/arch/ppc64/mm/hash_native.c |   47 ++++++++++++++++++-
 linux-2.6.12-rc3-mm3-sharada/include/asm-ppc64/mmu.h     |   22 ++++++++
 2 files changed, 68 insertions(+), 1 deletion(-)

diff -puN arch/ppc64/mm/hash_native.c~ppc64-native-hash-clear arch/ppc64/mm/hash_native.c
--- linux-2.6.12-rc3-mm3/arch/ppc64/mm/hash_native.c~ppc64-native-hash-clear	2005-05-05 20:15:16.718136192 +0530
+++ linux-2.6.12-rc3-mm3-sharada/arch/ppc64/mm/hash_native.c	2005-05-05 20:15:22.587175016 +0530
@@ -304,6 +304,50 @@ static void native_hpte_invalidate(unsig
 	local_irq_restore(flags);
 }
 
+/*
+ * clear all mappings on kexec.  All cpus are in real mode (or they will
+ * be when they isi), and we are the only one left.  We rely on our kernel
+ * mapping being 0xC0's and the hardware ignoring those two real bits.
+ *
+ * TODO: add batching support when enabled.  remember, no dynamic memory here,
+ * athough there is the control page available...
+ */
+static void native_hpte_clear(void)
+{
+	unsigned long slot, slots, flags;
+	HPTE *hptep = htab_address;
+	Hpte_dword0 dw0;
+	unsigned long pteg_count;
+
+	pteg_count = htab_hash_mask + 1;
+
+	local_irq_save(flags);
+
+	/* we take the tlbie lock and hold it.  Some hardware will
+	 * deadlock if we try to tlbie from two processors at once.
+	 */
+	spin_lock(&native_tlbie_lock);
+
+	slots = pteg_count * HPTES_PER_GROUP;
+
+	for (slot = 0; slot < slots; slot++, hptep++) {
+		/*
+		 * we could lock the pte here, but we are the only cpu
+		 * running,  right?  and for crash dump, we probably
+		 * don't want to wait for a maybe bad cpu.
+		 */
+		dw0 = hptep->dw0.dw0;
+
+		if (dw0.v) {
+			hptep->dw0.dword0 = 0;
+			tlbie(slot2va(dw0.avpn, dw0.l, dw0.h, slot), dw0.l);
+		}
+	}
+
+	spin_unlock(&native_tlbie_lock);
+	local_irq_restore(flags);
+}
+
 static void native_flush_hash_range(unsigned long context,
 				    unsigned long number, int local)
 {
@@ -415,7 +459,8 @@ void hpte_init_native(void)
 	ppc_md.hpte_updatepp	= native_hpte_updatepp;
 	ppc_md.hpte_updateboltedpp = native_hpte_updateboltedpp;
 	ppc_md.hpte_insert	= native_hpte_insert;
-	ppc_md.hpte_remove     	= native_hpte_remove;
+	ppc_md.hpte_remove	= native_hpte_remove;
+	ppc_md.hpte_clear_all	= native_hpte_clear;
 	if (tlb_batching_enabled())
 		ppc_md.flush_hash_range = native_flush_hash_range;
 	htab_finish_init();
diff -puN include/asm-ppc64/mmu.h~ppc64-native-hash-clear include/asm-ppc64/mmu.h
--- linux-2.6.12-rc3-mm3/include/asm-ppc64/mmu.h~ppc64-native-hash-clear	2005-05-05 20:15:16.771128136 +0530
+++ linux-2.6.12-rc3-mm3-sharada/include/asm-ppc64/mmu.h	2005-05-05 20:15:22.588174864 +0530
@@ -180,6 +180,28 @@ static inline void tlbiel(unsigned long 
 	asm volatile("ptesync": : :"memory");
 }
 
+static inline unsigned long slot2va(unsigned long avpn, unsigned long large,
+		unsigned long secondary, unsigned long slot)
+{
+	unsigned long va;
+
+	va = avpn << 23;
+
+	if (!large) {
+		unsigned long vpi, pteg;
+
+		pteg = slot / HPTES_PER_GROUP;
+		if (secondary)
+			pteg = ~pteg;
+
+		vpi = ((va >> 28) ^ pteg) & htab_hash_mask;
+
+		va |= vpi << PAGE_SHIFT;
+	}
+
+	return va;
+}
+
 /*
  * Handle a fault by adding an HPTE. If the address can't be determined
  * to be valid via Linux page tables, return 1. If handled return 0
_

  reply	other threads:[~2005-05-06 12:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-06  6:28 [PATCH] ppc64: global interrupt queue cleanup Paul Mackerras
2005-05-06 12:41 ` R Sharada [this message]
2005-05-06 12:44   ` [PATCH] ppc64: kexec support for ppc64 R Sharada
2005-05-06 23:05     ` Andrew Morton
2005-05-06 23:40       ` Gerrit Huizenga
2005-05-07  0:32         ` Andrew Morton
2005-05-07  2:02           ` Gerrit Huizenga
2005-05-07  2:36           ` Paul Mackerras
2005-05-07  8:40       ` [Fastboot] " Dipankar Sarma
2005-05-07 16:49       ` Suparna Bhattacharya
2005-05-09 11:55         ` Maneesh Soni
2005-05-09 12:05       ` R Sharada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050506124158.GA2741@in.ibm.com \
    --to=sharada@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.