TODO revision 1.25
1 /* $NetBSD: TODO,v 1.25 2018/02/03 21:45:54 palle Exp $ */ 2 3Things to be done: 4 5common: 6- make %g6 point to curcpu 7- make %g7 point to curlwp 8- change run-time checks for cpu type to function pointers 9 10sun4u: 11- GENERIC.UP kernel hangs on v445 (missing interrupt?) 12 13sun4v: 14 - current status: The kernel boots and starts the init process (syscalls are done, but crashes...) (*) 15- 64-bit kernel support 16- 32-bit kernel support 17- libkvm 18- ofwboot: tlb_init_sun4v() hardcodes number of slots to 64 19- locore.s: sun4v_datatrap missing implementation for trap level 1 20- check build without SUN4V defined 21- replace relevant references to %ver with GET_MAXCWP 22- pmap_mp_init(): sun4v missing handling 23- replace constructs like "wrpr %g0, PSTATE_KERN, %pstate" with NORMAL_GLOBALS 24- replace constructs line "wrpr %g0, PSTATE_INTR, %pstate" with ALTERNATE_GOBALS 25- sun4v tsb no need to lock... per cpu... anyway... 26- ci_tsb_desc->td_ctxidx: -1 or 1? 27- MP support - currently bypassed in pmap_bootstrap() for sun4v 28- vpci.c/vpcivar.h: cleanup FIXMEs 29- interrups not handled properly (com at ebus only...) 30- mpt(4) complains: mpt0: Phy 0: Link Status Unknown 31- man pages for drivers imported from OpenBSD lke vpci, vbus, cbus, vdsk, ldc etc. 32- vdsk and ldc drivers: code maked with OPENBSD_BUSDMA - make the bus_dma stuff work properly 33- vbus.c: handle prom_getprop() memory leaks 34- locore.s: rft_user (sun4v specific manaul fill) - seems to work, but is it good enough (compared to openbsds rft_user? 35 36 37(*) 38The current state of the code crashes in the code path after the init process 39(pid 1) does a fork(), starting pid 2. 40A new lwp is created and lwp_trampoline() is called which in turn calls 41return_from_trap(). Here the code path continues to rft_user(). 42A trap (0x68 - this is a Hyper-Priv trap...) occurs in rft_user_fault_start() 43where the FILL() macro causes the trap trying to load the local register %l0 44from the stack using ASI AIUS (%o6 contains 0xffffffffffffcd91). 45The Hyper-Priv trap 0x68 is transformed to a Priv trap 0x31, causing 46sun4v_dtsb_miss() to be called, continuing to sun4v_datatrap(). 47Here TRAP_SETUP() is called, 48The windows registers are now: %otherwin=0, %cansave=6, canrestore=0. 49Part of the TRAP_SETUP() code will do a 'save %g6, 0, %sp', 50The windows registers are now: %otherwin=0, %cansave=5, canrestore=1. 51TRAP_SETUP() now updates %otherwin with the values of %canrestore and clears 52%canrestore, so the windows registers are now: %otherwin=1, %cansave=5, 53canrestore=0. 54The execution continues to data_access_fault() and further down the call stack 55with function calls until %cansave reaches 0 causing a spill trap 56(0xa8 - spill_2_other). The contents of the %sp register is 0x00000000e00xxxxx. 57%wstate is (octal) 26. 58The windows registers are now: %otherwin=1, %cansave=0, canrestore=5. 59The spill code is using ASI AIUS. spill_2_other is selected since %otherwin is 60non-zero, so the index in wstate.other is 2 (spill_2_other). 61SPILLBOTH() is invoked, using ASI AIUS. While storing %l0 to %sp+0x7ff 62(%sp is 0xffffffffffffcd91) a new trap occurs, 0x68 (Hyper-priv, e.g. 0x31 Priv) 63at trap level 2 causing the trap level to go to 3. This is above the mx trap 64level for sun4v which is 2... 65So... the first access to 0xffffffffffffcd91 causes a cyclic access to 660xffffffffffffcd91 again causing the max trap level to exceed. 67hm....how to fix this.......... 68 69 70 71 72