Date: Tue, 15 Apr 2008 09:51:14 -0700 From: Peter Grehan <grehan@freebsd.org> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU Message-ID: <4804DD02.10304@freebsd.org> In-Reply-To: <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com> References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <5CC81F06-7B59-4163-9AB8-2ACE4235A5AA@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ? Stack *overflow* exception handling may be busted, but that is a challenging problem to get right. > Also, with process address space limited to 2G Where's that limitation ? If so, that's a bug: it should be 4G. > I wonder why we > keep swapping all segment registers and not just the lower 8? As above. That was taken from NetBSD to give the full 4G address space for users. It used to be the high 8 seg regs, since the lower 2G was either 1:1 BAT-mapped memory or PCI mem space. > 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 ? later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4804DD02.10304>