8xx-2.6 | MM tweaks

Hi

The following patch consists of minor tweaks in order to get the mm to work.

Regards

Pantelis

 arch/ppc/kernel/head_8xx.S |   10 ++++++++++
 arch/ppc/mm/fault.c        |   24 +++++++++++++++++-------
 arch/ppc/mm/init.c         |    2 ++
 include/asm-ppc/tlbflush.h |    3 +++
 4 files changed, 32 insertions(+), 7 deletions(-)

I was wondering. The fault.c change boils down to:
===== arch/ppc/mm/fault.c 1.26 vs edited =====

@@ -350,11 +350,14 @@
 	pgd_t *dir;
 	pmd_t *pmd;
 	pte_t *pte;
+	struct mm_struct *mm;
 
 	if (address < TASK_SIZE)
-		return NULL;
+		mm = current->mm;
+	else
+		mm = &init_mm;
 
-	dir = pgd_offset(&init_mm, address);
+	dir = pgd_offset(mm, address & PAGE_MASK);
 	if (dir) {
 		pmd = pmd_offset(dir, address & PAGE_MASK);
 		if (pmd && pmd_present(*pmd)) {

Can you explain this a bit more? Looking back at the history in BitKeeper, this change came from Paul, in the changeset with the comments of:
PPC update for the recent changes to the pgd/pmd/pte functions. This implements ptes-in-highmem for PPC, removes the quicklist and zero-page stuff. PTEs in highmem on SMP turned out to need some significant changes to avoid deadlocks on the hash_table_lock (now renamed to mmu_hash_lock). The PMDs now contain the physical address of the PTE page rather than the virtual address. Anything that takes the mmu_hash_lock now operates with the DMMU off to avoid MMU hash-table misses.

And for this file in particular:
Do pte_unmap after get_pteptr; use pte_offset_kernel instead of pte_offset in a couple of places.

Which you exactly reverted. Were the changes from Paul incorrect here? Or is perhaps there something more needed on the 8xx side of things?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Let me tell you, I didn't know any of this stuff :).

My algorithm for the changes was simple.

1. Assume that linuxppc_2.4 is more recent that linuxppc-2.5 on 8xx.
2. Forward port any significant changes to 2.5.
3. Test.

If this didn't work, then I would try to fix anything more complicated.

Thankfully it wasn't neccesary.

Regards

Pantelis

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

OK....I'll review these a little more closely :-)

Thanks.

	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

The problem with the old code (which Pantelis put back) is that PTEs no longer necessarily have fixed, unique virtual addresses in the kernel. Now that we can have PTE pages in highmem, it is necessary to use pte_offset_map to get the address of a PTE (which does a kmap if you have HIGHMEM enabled) and pte_unmap when you are finished with it. The address you get back from pte_offset_map is only valid until you do pte_unmap, and you can't sleep between pte_offset_map and pte_unmap (it uses an atomic kmap).

However, PTE pages for kernel mappings are allocated in lowmem, and you can get a persistent kernel virtual address for them.

Those changes were in va_to_pte, and the only user of that (that I can find) is va_to_phys, which isn't called at all AFAICS (and shouldn't be needed). Probably the best thing is just to remove them. In addition, get_8xx_pte and print_8xx_pte appear to be used only in some debugging code in softemu8xx.c, and could probably be dispensed with (another #ifdef gone, yay :). Certainly users of get_8xx_pte could use get_pteptr instead.

Paul.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/