From owner-freebsd-hackers Fri Sep 18 12:14:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12563 for freebsd-hackers-outgoing; Fri, 18 Sep 1998 12:14:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12557 for ; Fri, 18 Sep 1998 12:14:19 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA15433; Fri, 18 Sep 1998 13:07:04 -0600 (MDT) Date: Fri, 18 Sep 1998 13:07:04 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809181907.NAA15433@narnia.plutotech.com> To: Mike Smith cc: hackers@FreeBSD.ORG, Scott Smyth Subject: Re: memory allocation above "physical" memory Newsgroups: pluto.freebsd.hackers In-Reply-To: <199809181706.KAA00787@word.smith.net.au> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199809181706.KAA00787@word.smith.net.au> you wrote: >> If the kernel is hacked to only know about 64 MB, is there >> functionality already in the BSD kernel so allocate the memory >> that may lie above what the kernel "knows" about. For instance, >> in linux, vremap builds new page tables and returns a virtual >> address you can use. So, I am looking for a function that >> retrieves memory the kernel does not know about necessarily and >> maps it to virtual addresses (whether or not it is contigous in >> physical memory -- it may be). >> >> The example: physical memory the kernel knows: 64 MB, but the >> real memory banks hold 96 MB. How can I access the top 32 MB? >> Does functionality exist for: >> 1) getting page tables; >> 2) mapping page tables to virtual addresses. > > In most cases this is already taken care of; there should be no systems > on which physical memory is not correctly sized if you are running a > recent release or 3.0-current. Although I don't know why Scott wants to map this memory into kernel virtual memory (does the kernel or userland app need to grovel through the data???), I know that he has purposefully "stolen" the memory from the kernel. My guess is that the easiest way to map this into the kernel virtual address space is via pmap_mapdev(). To get this mapped into a userland process would probably require a device driver with a mmap entry point. > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message