From owner-freebsd-ia64 Mon Feb 26 15:23:30 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id C8F0837B401 for ; Mon, 26 Feb 2001 15:23:28 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1QNK9l49469 for ; Mon, 26 Feb 2001 15:20:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 26 Feb 2001 15:23:11 -0800 (PST) From: John Baldwin To: ia64@FreeBSD.org Subject: Grrrr.. Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, I've got ski up and running, and the kernel panics very early in boot because it tries to initialize a mutex for a zalloc zone far too early. The problem is due to pmap_bootstrap() using a zbootinit()'d zone. Now, I could just hack around this if we need that zalloc zone, but pmap_bootstrap has this comment above the code in question: /* * We need some PVs to cope with pmap_kenter() calls prior to * pmap_init(). This is all a bit flaky and needs to be * rethought, probably by avoiding the zone allocator * entirely. */ so I'm wondering if it might not be better to try and fix it as the comment suggests instead? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Feb 27 1:27:47 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id C849A37B718; Tue, 27 Feb 2001 01:27:44 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 14XgQ2-000KjA-0X; Tue, 27 Feb 2001 09:27:43 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f1R9Rg129758; Tue, 27 Feb 2001 09:27:42 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 27 Feb 2001 09:27:42 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: ia64@FreeBSD.org Subject: Re: Grrrr.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 26 Feb 2001, John Baldwin wrote: > Ok, I've got ski up and running, and the kernel panics very early in boot > because it tries to initialize a mutex for a zalloc zone far too early. The > problem is due to pmap_bootstrap() using a zbootinit()'d zone. Now, I could > just hack around this if we need that zalloc zone, but pmap_bootstrap has this > comment above the code in question: > > /* > * We need some PVs to cope with pmap_kenter() calls prior to > * pmap_init(). This is all a bit flaky and needs to be > * rethought, probably by avoiding the zone allocator > * entirely. > */ > > so I'm wondering if it might not be better to try and fix it as the comment > suggests instead? I think it would be a good idea. Basically, we need to be able to cope with the calls to pmap_map() which the VM system makes during initialisation. I'm not sure exactly how many there are - perhaps we can map them all using translation registers, which would be nice. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Feb 27 11:28:57 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 82A3937B719 for ; Tue, 27 Feb 2001 11:28:55 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f1RJPLl80802; Tue, 27 Feb 2001 11:25:21 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 27 Feb 2001 11:28:37 -0800 (PST) From: John Baldwin To: Doug Rabson Subject: Re: Grrrr.. Cc: ia64@FreeBSD.org Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 27-Feb-01 Doug Rabson wrote: > On Mon, 26 Feb 2001, John Baldwin wrote: > >> Ok, I've got ski up and running, and the kernel panics very early in boot >> because it tries to initialize a mutex for a zalloc zone far too early. The >> problem is due to pmap_bootstrap() using a zbootinit()'d zone. Now, I could >> just hack around this if we need that zalloc zone, but pmap_bootstrap has >> this >> comment above the code in question: >> >> /* >> * We need some PVs to cope with pmap_kenter() calls prior to >> * pmap_init(). This is all a bit flaky and needs to be >> * rethought, probably by avoiding the zone allocator >> * entirely. >> */ >> >> so I'm wondering if it might not be better to try and fix it as the comment >> suggests instead? > > I think it would be a good idea. Basically, we need to be able to cope > with the calls to pmap_map() which the VM system makes during > initialisation. I'm not sure exactly how many there are - perhaps we can > map them all using translation registers, which would be nice. That would be ideal, yes. :) I guess I'll read up some more on the VM stuff in the ia64 docco and see if I can make some sense of it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Feb 27 22: 1:55 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from devil1.arpnetworks.com (devil1.arpnetworks.com [206.171.92.96]) by hub.freebsd.org (Postfix) with SMTP id 6BF1337B718 for ; Tue, 27 Feb 2001 22:01:52 -0800 (PST) (envelope-from root@devil1.arpnetworks.com) Received: (qmail 26074 invoked by uid 501); 28 Feb 2001 06:12:24 -0000 Date: 28 Feb 2001 06:12:24 -0000 Message-ID: <20010228061224.26073.qmail@devil1.arpnetworks.com> To: freebsd-ia64@FreeBSD.org Subject: BSDSearch.Com - !New! Search Engine for BSD Users From: bsdjesus@bsdsearch.com X-Mailer: Postlister 1,16 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org BSDSearch.com http://www.bsdsearch.com is a new search engine for BSD Users around the Glove. It aims to be the largest indexed directory on the 'net for BSD Users. BSDSearch is by far the easiest way to find resources for iBSD, FreeBSD, NetBSD, OpenBSD and Anything Related to BSD. For more information contact bsdjesus@bsdsearch.com, webmaster@bsdsearch.com or reply to this e-mail. To be removed from the list,simply reply with remove in the subject head and we will remove your name. http://www.bsdsearch.com -- BSDSearch.com The Worlds Largest Directory and Search Engine for BSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Mar 1 8:25:29 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 480F937B71A; Thu, 1 Mar 2001 08:25:20 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 14YVtG-000Nlu-0A; Thu, 1 Mar 2001 16:25:18 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f21GPH142213; Thu, 1 Mar 2001 16:25:17 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 1 Mar 2001 16:25:17 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: Grrrr.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 27 Feb 2001, John Baldwin wrote: > > On 27-Feb-01 Doug Rabson wrote: > > I think it would be a good idea. Basically, we need to be able to cope > > with the calls to pmap_map() which the VM system makes during > > initialisation. I'm not sure exactly how many there are - perhaps we can > > map them all using translation registers, which would be nice. > > That would be ideal, yes. :) I guess I'll read up some more on the VM stuff in > the ia64 docco and see if I can make some sense of it. I remember now. I always intended to redo pmap_map() via the direct-mapped segments. This saves kernel virtual address space (of which there is plenty) but more importantly saves TLB entries and on ia64 VHTP entries. I just hacked up this patch which isn't tested on anything but I think its on the right lines. Beware of conflicts - Drew Gallatin is working in this area. Index: alpha/alpha/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/pmap.c,v retrieving revision 1.51 diff -u -r1.51 pmap.c --- alpha/alpha/pmap.c 2001/01/30 00:35:35 1.51 +++ alpha/alpha/pmap.c 2001/03/01 16:21:21 @@ -898,6 +898,24 @@ return (virt); } +/* + * Used to map a range of physical addresses into kernel + * virtual address space. + * + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. + */ +vm_offset_t +pmap_map(vm_offset_t *virt, vm_offset_t start, vm_offset_t end, int prot) +{ + return ALPHA_PHYS_TO_K0SEG(start); +} + static vm_page_t pmap_page_lookup(vm_object_t object, vm_pindex_t pindex) Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.272 diff -u -r1.272 pmap.c --- i386/i386/pmap.c 2001/01/30 00:35:34 1.272 +++ i386/i386/pmap.c 2001/03/01 16:20:03 @@ -712,22 +712,30 @@ * Used to map a range of physical addresses into kernel * virtual address space. * - * For now, VM is already on, we only need to map the - * specified memory. + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. */ vm_offset_t pmap_map(virt, start, end, prot) - vm_offset_t virt; + vm_offset_t *virt; vm_offset_t start; vm_offset_t end; int prot; { + vm_offset_t sva = *virtp; + vm_offset_t va = sva; while (start < end) { - pmap_kenter(virt, start); - virt += PAGE_SIZE; + pmap_kenter(va, start); + va += PAGE_SIZE; start += PAGE_SIZE; } - return (virt); + *virt = va; + return (sva); } Index: ia64/ia64/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/pmap.c,v retrieving revision 1.11 diff -u -r1.11 pmap.c --- ia64/ia64/pmap.c 2001/01/21 22:23:10 1.11 +++ ia64/ia64/pmap.c 2001/03/01 16:21:13 @@ -1115,22 +1115,18 @@ * Used to map a range of physical addresses into kernel * virtual address space. * - * For now, VM is already on, we only need to map the - * specified memory. + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. */ vm_offset_t -pmap_map(vm_offset_t virt, vm_offset_t start, vm_offset_t end, int prot) +pmap_map(vm_offset_t *virt, vm_offset_t start, vm_offset_t end, int prot) { - /* - * XXX We should really try to use larger pagesizes here to - * cut down the number of PVs used. - */ - while (start < end) { - pmap_kenter(virt, start); - virt += PAGE_SIZE; - start += PAGE_SIZE; - } - return (virt); + return IA64_PHYS_TO_RR7(start); } /* Index: vm/pmap.h =================================================================== RCS file: /home/ncvs/src/sys/vm/pmap.h,v retrieving revision 1.37 diff -u -r1.37 pmap.h --- vm/pmap.h 2000/10/17 10:05:49 1.37 +++ vm/pmap.h 2001/03/01 16:18:30 @@ -110,7 +110,7 @@ boolean_t pmap_ts_referenced __P((vm_page_t m)); void pmap_kenter __P((vm_offset_t va, vm_offset_t pa)); void pmap_kremove __P((vm_offset_t)); -vm_offset_t pmap_map __P((vm_offset_t, vm_offset_t, vm_offset_t, int)); +vm_offset_t pmap_map __P((vm_offset_t *, vm_offset_t, vm_offset_t, int)); void pmap_object_init_pt __P((pmap_t pmap, vm_offset_t addr, vm_object_t object, vm_pindex_t pindex, vm_offset_t size, int pagelimit)); Index: vm/vm_page.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_page.c,v retrieving revision 1.156 diff -u -r1.156 vm_page.c --- vm/vm_page.c 2000/12/26 19:41:38 1.156 +++ vm/vm_page.c 2001/03/01 16:17:39 @@ -242,8 +242,6 @@ * * Note: This computation can be tweaked if desired. */ - vm_page_buckets = (struct vm_page **)vaddr; - bucket = vm_page_buckets; if (vm_page_bucket_count == 0) { vm_page_bucket_count = 1; while (vm_page_bucket_count < atop(total)) @@ -255,16 +253,16 @@ /* * Validate these addresses. */ - new_start = start + vm_page_bucket_count * sizeof(struct vm_page *); new_start = round_page(new_start); - mapped = round_page(vaddr); - vaddr = pmap_map(mapped, start, new_start, + mapped = pmap_map(&vaddr, start, new_start, VM_PROT_READ | VM_PROT_WRITE); + bzero((caddr_t) mapped, new_start - start); start = new_start; - vaddr = round_page(vaddr); - bzero((caddr_t) mapped, vaddr - mapped); + vm_page_buckets = (struct vm_page **)mapped; + bucket = vm_page_buckets; + for (i = 0; i < vm_page_bucket_count; i++) { *bucket = NULL; bucket++; @@ -275,7 +273,6 @@ * use (taking into account the overhead of a page structure per * page). */ - first_page = phys_avail[0] / PAGE_SIZE; page_range = phys_avail[(nblocks - 1) * 2 + 1] / PAGE_SIZE - first_page; @@ -286,16 +283,11 @@ * Initialize the mem entry structures now, and put them in the free * queue. */ - vm_page_array = (vm_page_t) vaddr; - mapped = vaddr; - - /* - * Validate these addresses. - */ new_start = round_page(start + page_range * sizeof(struct vm_page)); - mapped = pmap_map(mapped, start, new_start, + mapped = pmap_map(&vaddr, start, new_start, VM_PROT_READ | VM_PROT_WRITE); start = new_start; + vm_page_array = (vm_page_t) mapped; first_managed_page = start / PAGE_SIZE; -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Mar 1 8:36: 8 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 3C85337B71A; Thu, 1 Mar 2001 08:36:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14YW3h-000HG9-0K; Thu, 1 Mar 2001 16:36:05 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f21Ga4142262; Thu, 1 Mar 2001 16:36:04 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 1 Mar 2001 16:36:04 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: Grrrr.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 1 Mar 2001, Doug Rabson wrote: > On Tue, 27 Feb 2001, John Baldwin wrote: > > > > > On 27-Feb-01 Doug Rabson wrote: > > > I think it would be a good idea. Basically, we need to be able to cope > > > with the calls to pmap_map() which the VM system makes during > > > initialisation. I'm not sure exactly how many there are - perhaps we can > > > map them all using translation registers, which would be nice. > > > > That would be ideal, yes. :) I guess I'll read up some more on the VM stuff in > > the ia64 docco and see if I can make some sense of it. > > I remember now. I always intended to redo pmap_map() via the direct-mapped > segments. This saves kernel virtual address space (of which there is > plenty) but more importantly saves TLB entries and on ia64 VHTP entries. I > just hacked up this patch which isn't tested on anything but I think its > on the right lines. Beware of conflicts - Drew Gallatin is working in this > area. I just noticed that I forgot to delete the old version of pmap_map() in sys/alpha/alpha/pmap.c. You get the picture anyway. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Mar 2 4: 2: 6 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id AB6C437B72D; Fri, 2 Mar 2001 04:01:50 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 14YoFp-000IiZ-0K; Fri, 2 Mar 2001 12:01:49 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f22C1m146601; Fri, 2 Mar 2001 12:01:48 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 2 Mar 2001 12:01:48 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Subject: Re: Grrrr.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 27 Feb 2001, John Baldwin wrote: > That would be ideal, yes. :) I guess I'll read up some more on the VM stuff in > the ia64 docco and see if I can make some sense of it. I worked on this some more. Fixing pmap_map() removes most of the calls to get_pv_entry which happen before pmap_init(). There are still about 320 calls which actually happen *during* pmap_init() which can be covered by a static array. A kernel with this patch boots a bit further but dies later somewhere inside xpt_init (I think). Index: i386/i386/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.273 diff -u -r1.273 pmap.c --- i386/i386/pmap.c 2001/02/23 01:25:00 1.273 +++ i386/i386/pmap.c 2001/03/02 10:52:18 @@ -711,22 +711,30 @@ * Used to map a range of physical addresses into kernel * virtual address space. * - * For now, VM is already on, we only need to map the - * specified memory. + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. */ vm_offset_t pmap_map(virt, start, end, prot) - vm_offset_t virt; + vm_offset_t *virt; vm_offset_t start; vm_offset_t end; int prot; { + vm_offset_t sva = *virtp; + vm_offset_t va = sva; while (start < end) { - pmap_kenter(virt, start); - virt += PAGE_SIZE; + pmap_kenter(va, start); + va += PAGE_SIZE; start += PAGE_SIZE; } - return (virt); + *virt = va; + return (sva); } Index: alpha/alpha/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/pmap.c,v retrieving revision 1.51 diff -u -r1.51 pmap.c --- alpha/alpha/pmap.c 2001/01/30 00:35:35 1.51 +++ alpha/alpha/pmap.c 2001/03/01 16:32:17 @@ -884,18 +884,18 @@ * Used to map a range of physical addresses into kernel * virtual address space. * - * For now, VM is already on, we only need to map the - * specified memory. + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. */ vm_offset_t -pmap_map(vm_offset_t virt, vm_offset_t start, vm_offset_t end, int prot) +pmap_map(vm_offset_t *virt, vm_offset_t start, vm_offset_t end, int prot) { - while (start < end) { - pmap_kenter(virt, start); - virt += PAGE_SIZE; - start += PAGE_SIZE; - } - return (virt); + return ALPHA_PHYS_TO_K0SEG(start); } Index: ia64/ia64/pmap.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/pmap.c,v retrieving revision 1.11 diff -u -r1.11 pmap.c --- ia64/ia64/pmap.c 2001/01/21 22:23:10 1.11 +++ ia64/ia64/pmap.c 2001/03/02 11:54:00 @@ -220,12 +220,9 @@ static vm_zone_t pvzone; static struct vm_zone pvzone_store; static struct vm_object pvzone_obj; -static vm_zone_t pvbootzone; -static struct vm_zone pvbootzone_store; static int pv_entry_count=0, pv_entry_max=0, pv_entry_high_water=0; static int pmap_pagedaemon_waken = 0; static struct pv_entry *pvinit; -static struct pv_entry *pvbootinit; static PMAP_INLINE void free_pv_entry __P((pv_entry_t pv)); static pv_entry_t get_pv_entry __P((void)); @@ -271,7 +268,6 @@ pmap_bootstrap() { int i; - int boot_pvs; /* * Setup RIDs. We use the bits above pmap_ridbits for a @@ -319,19 +315,6 @@ ia64_set_rr(IA64_RR_BASE(7), (7 << 8) | (28 << 2)); /* - * We need some PVs to cope with pmap_kenter() calls prior to - * pmap_init(). This is all a bit flaky and needs to be - * rethought, probably by avoiding the zone allocator - * entirely. - */ - boot_pvs = 32768; - pvbootzone = &pvbootzone_store; - pvbootinit = (struct pv_entry *) - pmap_steal_memory(boot_pvs * sizeof (struct pv_entry)); - zbootinit(pvbootzone, "PV ENTRY", sizeof (struct pv_entry), - pvbootinit, boot_pvs); - - /* * Set up proc0's PCB. */ #if 0 @@ -752,8 +735,23 @@ static pv_entry_t get_pv_entry(void) { - if (!pvinit) - return zalloc(pvbootzone); + /* + * We can get called a few times really early before + * pmap_init() has finished allocating the pvzone (mostly as a + * result of the call to kmem_alloc() in pmap_init(). We allow + * a small number of entries to be allocated statically to + * cover this. + */ + if (!pvinit) { +#define PV_BOOTSTRAP_NEEDED 512 + static struct pv_entry pvbootentries[PV_BOOTSTRAP_NEEDED]; + static int pvbootnext = 0; + + if (pvbootnext == PV_BOOTSTRAP_NEEDED) + panic("get_pv_entry: called too many times" + " before pmap_init is finished"); + return &pvbootentries[pvbootnext++]; + } pv_entry_count++; if (pv_entry_high_water && @@ -1115,22 +1113,18 @@ * Used to map a range of physical addresses into kernel * virtual address space. * - * For now, VM is already on, we only need to map the - * specified memory. + * The value passed in '*virt' is a suggested virtual address for + * the mapping. Architectures which can support a direct-mapped + * physical to virtual region can return the appropriate address + * within that region, leaving '*virt' unchanged. Other + * architectures should map the pages starting at '*virt' and + * update '*virt' with the first usable address after the mapped + * region. */ vm_offset_t -pmap_map(vm_offset_t virt, vm_offset_t start, vm_offset_t end, int prot) +pmap_map(vm_offset_t *virt, vm_offset_t start, vm_offset_t end, int prot) { - /* - * XXX We should really try to use larger pagesizes here to - * cut down the number of PVs used. - */ - while (start < end) { - pmap_kenter(virt, start); - virt += PAGE_SIZE; - start += PAGE_SIZE; - } - return (virt); + return IA64_PHYS_TO_RR7(start); } /* Index: vm/pmap.h =================================================================== RCS file: /home/ncvs/src/sys/vm/pmap.h,v retrieving revision 1.37 diff -u -r1.37 pmap.h --- vm/pmap.h 2000/10/17 10:05:49 1.37 +++ vm/pmap.h 2001/03/01 16:18:30 @@ -110,7 +110,7 @@ boolean_t pmap_ts_referenced __P((vm_page_t m)); void pmap_kenter __P((vm_offset_t va, vm_offset_t pa)); void pmap_kremove __P((vm_offset_t)); -vm_offset_t pmap_map __P((vm_offset_t, vm_offset_t, vm_offset_t, int)); +vm_offset_t pmap_map __P((vm_offset_t *, vm_offset_t, vm_offset_t, int)); void pmap_object_init_pt __P((pmap_t pmap, vm_offset_t addr, vm_object_t object, vm_pindex_t pindex, vm_offset_t size, int pagelimit)); Index: vm/vm_page.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_page.c,v retrieving revision 1.157 diff -u -r1.157 vm_page.c --- vm/vm_page.c 2001/03/01 19:21:24 1.157 +++ vm/vm_page.c 2001/03/02 10:57:47 @@ -242,8 +242,6 @@ * * Note: This computation can be tweaked if desired. */ - vm_page_buckets = (struct vm_page **)vaddr; - bucket = vm_page_buckets; if (vm_page_bucket_count == 0) { vm_page_bucket_count = 1; while (vm_page_bucket_count < atop(total)) @@ -257,12 +255,12 @@ */ new_end = end - vm_page_bucket_count * sizeof(struct vm_page *); new_end = trunc_page(new_end); - mapped = round_page(vaddr); - vaddr = pmap_map(mapped, new_end, end, + mapped = pmap_map(&vaddr, new_end, end, VM_PROT_READ | VM_PROT_WRITE); - vaddr = round_page(vaddr); - bzero((caddr_t) mapped, vaddr - mapped); + bzero((caddr_t) mapped, end - new_end); + vm_page_buckets = (struct vm_page **)mapped; + bucket = vm_page_buckets; for (i = 0; i < vm_page_bucket_count; i++) { *bucket = NULL; bucket++; @@ -281,20 +279,15 @@ (end - new_end)) / PAGE_SIZE; end = new_end; + /* * Initialize the mem entry structures now, and put them in the free * queue. */ - vm_page_array = (vm_page_t) vaddr; - mapped = vaddr; - - /* - * Validate these addresses. - */ - new_end = trunc_page(end - page_range * sizeof(struct vm_page)); - mapped = pmap_map(mapped, new_end, end, + mapped = pmap_map(&vaddr, new_end, end, VM_PROT_READ | VM_PROT_WRITE); + vm_page_array = (vm_page_t) mapped; /* * Clear all of the page structures -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Mar 2 12:43:28 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 089DE37B719; Fri, 2 Mar 2001 12:43:25 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id PAA29825; Fri, 2 Mar 2001 15:43:20 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.2/8.9.1) id f22Kgo807839; Fri, 2 Mar 2001 15:42:50 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15008.1482.524485.786926@grasshopper.cs.duke.edu> Date: Fri, 2 Mar 2001 15:42:50 -0500 (EST) To: Doug Rabson Cc: John Baldwin , Subject: Re: Grrrr.. In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Doug Rabson writes: > > I remember now. I always intended to redo pmap_map() via the direct-mapped > segments. This saves kernel virtual address space (of which there is > plenty) but more importantly saves TLB entries and on ia64 VHTP entries. I > just hacked up this patch which isn't tested on anything but I think its > on the right lines. Beware of conflicts - Drew Gallatin is working in this > area. > I'm done now (and your latest patch at the top of this thread incorporates my committed changes). I really like using the direct-mapped segment for this. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Mar 2 13: 2:36 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 074C937B718 for ; Fri, 2 Mar 2001 13:02:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f22KveA01017; Fri, 2 Mar 2001 12:57:40 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15008.1482.524485.786926@grasshopper.cs.duke.edu> Date: Fri, 02 Mar 2001 13:01:43 -0800 (PST) From: John Baldwin To: Andrew Gallatin Subject: Re: Grrrr.. Cc: ia64@FreeBSD.org, Doug Rabson Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 02-Mar-01 Andrew Gallatin wrote: > > Doug Rabson writes: > > > > I remember now. I always intended to redo pmap_map() via the direct-mapped > > segments. This saves kernel virtual address space (of which there is > > plenty) but more importantly saves TLB entries and on ia64 VHTP entries. I > > just hacked up this patch which isn't tested on anything but I think its > > on the right lines. Beware of conflicts - Drew Gallatin is working in this > > area. > > > > I'm done now (and your latest patch at the top of this thread > incorporates my committed changes). > > I really like using the direct-mapped segment for this. I'm going to test this out on my alpha and i386 test boxes here at work. If it works there, I think it should probably be committed. Not that I am overwhelmed with pmap Clue atm. :) > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Mar 3 3:11:52 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id CAEA937B718; Sat, 3 Mar 2001 03:11:48 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 14Z9wt-000Kj7-0B; Sat, 3 Mar 2001 11:11:43 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f23BBh153418; Sat, 3 Mar 2001 11:11:43 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 3 Mar 2001 11:11:43 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Andrew Gallatin , Subject: Re: Grrrr.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Mar 2001, John Baldwin wrote: > > On 02-Mar-01 Andrew Gallatin wrote: > > > > Doug Rabson writes: > > > > > > I remember now. I always intended to redo pmap_map() via the direct-mapped > > > segments. This saves kernel virtual address space (of which there is > > > plenty) but more importantly saves TLB entries and on ia64 VHTP entries. I > > > just hacked up this patch which isn't tested on anything but I think its > > > on the right lines. Beware of conflicts - Drew Gallatin is working in this > > > area. > > > > > > > I'm done now (and your latest patch at the top of this thread > > incorporates my committed changes). > > > > I really like using the direct-mapped segment for this. > > I'm going to test this out on my alpha and i386 test boxes here at work. > If it works there, I think it should probably be committed. Not that I > am overwhelmed with pmap Clue atm. :) I would appreciate it if you could test on i386 since I'm not currently in a position to to i386 kernel work. It certainly appears to work on ia64 and I don't expect problems on alpha (I'll probably test that myself shortly though). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message