 @@ -1,14 +1,14 @@
-/*	$NetBSD: pmap.c,v 1.255 2013/05/11 10:15:43 skrll Exp $	*/
+/*	$NetBSD: pmap.c,v 1.256 2013/06/12 07:13:18 matt Exp $	*/
 /*
  * Copyright 2003 Wasabi Systems, Inc.
  * All rights reserved.
+ *
  * Written by Steve C. Woodford for Wasabi Systems, Inc.
+ *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
 @@ -152,28 +152,28 @@
  *   - There are some unresolved issues for MP systems:
+ *
  *     o The L1 metadata needs a lock, or more specifically, some places
  *       need to acquire an exclusive lock when modifying L1 translation
  *       table entries.
+ *
  *     o When one cpu modifies an L1 entry, and that L1 table is also
  *       being used by another cpu, then the latter will need to be told
  *       that a tlb invalidation may be necessary. (But only if the old
  *       domain number in the L1 entry being over-written is currently
  *       the active domain on that cpu). I guess there are lots more tlb
  *       shootdown issues too...
+ *
- *     o If the vector_page is at 0x00000000 instead of 0xffff0000, then
+ *     o If the vector_page is at 0x00000000 instead of in kernel VA space,
- *       MP systems will lose big-time because of the MMU domain hack.
+ *       then MP systems will lose big-time because of the MMU domain hack.
  *       The only way this can be solved (apart from moving the vector
  *       page to 0xffff0000) is to reserve the first 1MB of user address
  *       space for kernel use only. This would require re-linking all
  *       applications so that the text section starts above this 1MB
  *       boundary.
+ *
  *     o Tracking which VM space is resident in the cache/tlb has not yet
  *       been implemented for MP systems.
+ *
  *     o Finally, there is a pathological condition where two cpus running
  *       two separate processes (not lwps) which happen to share an L1
  *       can get into a fight over one or more L1 entries. This will result
  *       in a significant slow-down if both processes are in tight loops.
 @@ -202,27 +202,27 @@
 #include <sys/cdefs.h>
 #include <sys/cpu.h>
 #include <sys/sysctl.h>
 #include <uvm/uvm.h>
 #include <sys/bus.h>
 #include <machine/pmap.h>
 #include <machine/pcb.h>
 #include <machine/param.h>
 #include <arm/cpuconf.h>
 #include <arm/arm32/katelib.h>
-__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.255 2013/05/11 10:15:43 skrll Exp $");
+__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.256 2013/06/12 07:13:18 matt Exp $");
 #ifdef PMAP_DEBUG
 /* XXX need to get rid of all refs to this */
 int pmap_debug_level = 0;
 /*
  * for switching to potentially finer grained debugging
  */
 #define	PDB_FOLLOW	0x0001
 #define	PDB_INIT	0x0002
 #define	PDB_ENTER	0x0004
 #define	PDB_REMOVE	0x0008
 @@ -5125,26 +5125,37 @@ out:
 /************************ Utility routines ****************************/
 /*
  * vector_page_setprot:
+ *
  *	Manipulate the protection of the vector page.
  */
 void
 vector_page_setprot(int prot)
+{
 	struct l2_bucket *l2b;
 	pt_entry_t *ptep;
 #if defined(CPU_ARMV7) || defined(CPU_ARM11)
 	/*
 	 * If we are using VBAR to use the vectors in the kernel, then it's
 	 * already mapped in the kernel text so no need to anything here.
 	 */
 	if (vector_page != ARM_VECTORS_LOW && vector_page != ARM_VECTORS_HIGH) {
 		KASSERT((armreg_pfr1_read() & ARM_PFR1_SEC_MASK) != 0);
 		return;
+	}
 #endif
 	l2b = pmap_get_l2_bucket(pmap_kernel(), vector_page);
 	KDASSERT(l2b != NULL);
 	ptep = &l2b->l2b_kva[l2pte_index(vector_page)];
 	*ptep = (*ptep & ~L2_S_PROT_MASK) | L2_S_PROT(PTE_KERNEL, prot);
 	PTE_SYNC(ptep);
 	cpu_tlb_flushD_SE(vector_page);
 	cpu_cpwait();
+}
 /*
  * Fetch pointers to the PDE/PTE for the given pmap/VA pair.