Date: Tue, 15 Apr 2008 10:40:03 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: grehan@freebsd.org Cc: freebsd-ppc@freebsd.org Subject: Re: kernel stacks [eas: Re: G5 Bridge-mode MMU] Message-ID: <058EEFE3-09D7-447A-93AB-3E90EC59ECDC@mac.com> In-Reply-To: <4804DD02.10304@freebsd.org> References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> <4804DD02.10304@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 15, 2008, at 9:51 AM, Peter Grehan wrote: > Hi Marcel, > >> There's a bigger problem though: the current AIM pmap code and >> exception handling is broken for kernel stacks. > > I've not seen any evidence of this. Granted, I've only tested with > psim, but I can safely access all of kstack0's virtual address > space. All of the stack pages are wired, as are the mappings. Where > are the DSI exceptions occurring ? Bus enumeration: usbd_new_device() is a known kernel stack hog. On my xserve the call-chain is deep enough that during bus-enumeration we actually run into the second kernel stack page. With the current implementation, this happens to be kstack0 and as such BAT-mapped. When we switch to the kernel stack allocated for thread0 (by pmap_bootstrap()) before we call mi_startup(), bus enumeration fails, because the second page happens to not be mapped - the not mapping means that the CPU couldn't find the translation in its TLB nor in the hash table. The exception code treats this as a kernel stack overflow. Another example is: if we get an interrupt while in kernel mode and the stack has been used enough that the trapframe crosses the page boundary, then we can get a page fault while constructing the trapframe. > Stack *overflow* exception handling may be busted, but that is a > challenging problem to get right. The logic currently assumes that there's never a DSI trap for the kernel stack. This simply is an invalid assumption. >> Also, with process address space limited to 2G > > Where's that limitation ? If so, that's a bug: it should be 4G. vmparam.h: #define VM_MAXUSER_ADDRESS 0x7ffff000 >> Related: how hard would it be to map the kernel above 2G and >> eliminate the SR swap in the exception handlers (but do it on >> context switches)? > > You would have to eliminate the 1:1 mapping. I know this was done in > the bookE port, and it is painful to have two kernel ABIs. > > How about the corollary: how hard is it to get the bookE port to use > a separate address space for the kernel ? Probably not too hard. We (i.e. Juniper) discussed this with Semihalf and for Juniper the single address space implementation was better, even though Semihalf started with the split address space. It makes sense to unify... I'll investigate... -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?058EEFE3-09D7-447A-93AB-3E90EC59ECDC>