PERFORCE change 154804 for review

[Nathan Whitehorn]

http://perforce.freebsd.org/chv.cgi?CH=154804

Change 154804 by nwhitehorn at nwhitehorn_trantor on 2008/12/16 17:17:59

	Drop the static buffer. We can get away without it, using
	pmap_kextract(), on the assumption that memory in this critical time
	will still have a physical address in the 32-bit range. This issue
	should be revisited in future.

Affected files ...

.. //depot/projects/ppc-g5/sys/powerpc/ofw/ofw_real.c#5 edit

Differences ...

==== //depot/projects/ppc-g5/sys/powerpc/ofw/ofw_real.c#5 (text+ko) ====

@@ -157,14 +157,8 @@
 static struct mtx	of_bounce_mtx;
 
 /*
- * We need a statically allocated bounce buffer to handle the case when
- * there are Open Firmware calls after the MMU has been enabled but before
- * the VM has been initialized to the point that we can allocate memory.
- * Make it 256 bytes and 8 byte aligned and hope for the best.
- *
- * After the VM is up, allocate more memory.
+ * After the VM is up, allocate a wired, low memory bounce page.
  */
-static uint64_t		of_static_bounce_buffer[32];
 
 static void ofw_real_bounce_alloc(void *);
 
@@ -220,10 +214,14 @@
 		if (!pmap_bootstrapped)
 			return (cell_t)buf;
 
-		of_bounce_virt = (caddr_t)of_static_bounce_buffer;
-		of_bounce_size = sizeof(of_static_bounce_buffer);
-
-		of_bounce_phys = vtophys(of_static_bounce_buffer);
+		/*
+		 * XXX: It is possible for us to get called before the VM has
+		 * come online, but after the MMU is up. We don't have the
+		 * bounce buffer yet, but can no longer presume a 1:1 mapping.
+		 * Grab the physical address of the buffer, and hope it is
+		 * in range if this happens.
+		 */
+		return (cell_t)vtophys(buf);
 	}
 
 	/*