Date: Tue, 31 Oct 2000 07:30:03 -0800 (PST) From: William J Carpenter <carp@world.std.com> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000 Message-ID: <200010311530.HAA23005@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/22441; it has been noted by GNATS.
From: William J Carpenter <carp@world.std.com>
To: dg@root.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: i386/22441: pmap_growkernel() is not effective at kernel vm limit of 0xffc00000
Date: Tue, 31 Oct 2000 10:20:20 -0500 (EST)
cc: freebsd-gnats-submit@FreeBSD.ORG
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 31 Oct 2000 06:23:19 -0800
Sender: dg@implode.root.com
>When called with a kernel vm limit of 0xffc00000, pamp_growkernel()
>does not set-up the page mapping hardware because of an overflow.
>
>In this line:
>
> addr = (addr + PAGE_SIZE * NPTEPG) & ~(PAGE_SIZE * NPTEPG - 1);
> ( Line 1403 in $FreeBSD: src/sys/i386/i386/pmap.c,v 1.250.2.5 2000/08/05 00:39:08 peter Exp $)
>
>addr + PAGE_SIZE * NPTEPG overflows to zero when addr is 0xffc00000.
I might not be understanding what you're doing exactly,
I am not sure that what I am doing is strictly necessary, but
I can successfully allocate kernel vm this way in BSDI.
but I
should point out that the alternate page table map (APTmap) starts
at 0xffc00000, so I don't see how you could ever use that area of
virtual memory without serious problems. What am I missing?
That's good to know.
The problem is that 0xffc00000 is passed as a limit to pmap_growkernel().
I am not using 0xffc00000, I am using memory up to 0xffc00000 which
is the advertised limit to kernel vm. (kernel_map->header.end)
(kgdb) print /x * kernel_map
$221 = {header = {prev = 0xc02c1d60, next = 0xc02c1f70, start = 0xbfeff000,
end = 0xffc00000, avail_ssize = 0x0, object = {vm_object = 0x0,
sub_map = 0x0}, offset = 0x0, eflags = 0x0, protection = 0x0,
max_protection = 0x0, inheritance = 0x0, wired_count = 0x0, lastr = 0x0},
lock = {lk_interlock = {lock_data = 0x0}, lk_flags = 0x1000000,
lk_sharecount = 0x0, lk_waitcount = 0x0, lk_exclusivecount = 0x0,
lk_prio = 0x4, lk_wmesg = 0xc0277da0, lk_timo = 0x0,
lk_lockholder = 0xffffffff}, nentries = 0x9, size = 0x1e531000,
system_map = 0x1, hint = 0xc02c1d60, timestamp = 0x21,
first_free = 0xc02c1d00, pmap = 0xc02cf8c0}
Pmap_growkernel()'s job is to set-up the physical page mappings to
cover the increased kernel vm. In order to do this on the i386
architecture, a page map directory entry must be made for every
4mbytes of memory. The kernel vm layer rounds vm up to a page
boundary. The physical map layer must round-up a 4mbyte boundary
because of the two level i386 page mapping hierarchy.
If the vm layer kernel memory limit falls on a page boundary,
but not on a page directory boundary, say 0xffb01000,
then as far as physical map layer is concerned, a page directory
entry must be created to cover vm from 0xffb00000 to 0xffbfffff.
If the vm layer limit falls on 0xffb00000, this means that
the kernel requested vm in the range 0xffaff000 to 0xffafffff.
The vm layer rounds this address up to 0xffb00000 and declares
that this is the limit for pmap_growkernel(). In the case where
the limit is 0xffb00000, pmap_growkernel actually makes a
page directory entry for adresses >= 0xffb00000 -- a harmless
sort of overflow which merely sucks up an extra page of memory.
In the case where the kernel vm grows to the range of
[ 0xffbff001, 0xffc00000-1 ], (the page below 0xffc00000, in this
case, kernel vm requested explicitly by me), pmap_growkernel()
overflows by rounding 0xffc0000 up to the next 4m boundary which
on 32-bit machines is 0.
I hope this helps explain what I think is a problem.
Bill
--
Bill Carpenter carp@world.std.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010311530.HAA23005>