kernel stacks [eas: Re: G5 Bridge-mode MMU]

[Marcel Moolenaar]

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 at mac.com