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