[src/trunk]: src/sys/arch/sparc64/doc sun4v: update TODO with analysis of sun...

[palle <palle%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/e7f5481275c3
branches:  trunk
changeset: 1018365:e7f5481275c3
user:      palle <palle%NetBSD.org@localhost>
date:      Sun Jan 31 19:08:05 2021 +0000

description:
sun4v: update TODO with analysis of sun4v crashes

diffstat:

 sys/arch/sparc64/doc/TODO |  21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)

diffs (35 lines):

diff -r 5f8ac7da48fa -r e7f5481275c3 sys/arch/sparc64/doc/TODO
--- a/sys/arch/sparc64/doc/TODO Sun Jan 31 18:31:59 2021 +0000
+++ b/sys/arch/sparc64/doc/TODO Sun Jan 31 19:08:05 2021 +0000
@@ -1,4 +1,4 @@
-/* $NetBSD: TODO,v 1.31 2021/01/04 15:13:50 skrll Exp $ */
+/* $NetBSD: TODO,v 1.32 2021/01/31 19:08:05 palle Exp $ */
 
 Things to be done:
 
@@ -11,9 +11,22 @@
 - GENERIC.UP kernel hangs on v445 (missing interrupt?)
 
 sun4v:
- - current status: The kernel boots and starts the init process.
-   The following processes seem to crash on and on so more debugging to be done...
-
+ - current status:
+     The kernel boots and starts userland.
+        During the execution of the sysinst process, a sub-process crashes.
+        The crash happens when a call to sysctl from /bin/sh causes a mmu trap.
+        Part of the TRAP_SETUP() call in sun4v_datatrap issues a 'save' instruction.
+        Since %cansave is 0 (%canrestore is 6 and %otherwin is 0) a SPILL trap is generated.
+        The current code ends up in the pcbspill codepath (which is based on code from openbsd).
+        This code assumes that it is the register window in the OTHERWIN window that must be spilled
+        to the pcb.
+        Since %otherwin in this scenario actually is zero, we end up putting incorrect register
+        window values to the pcb.
+        So - this code should not save data to the pcb when %otherwin is 0 - it should spill the
+        values to the stack of the user process. Special care should be taken here, since we
+        may end up with a mmu fault again if the stack address is not present in the mmu, so
+        perhaps spilling to the physical address of the stack will work.
+        Time will show if this is correct...
 - 64-bit kernel support
 - 32-bit kernel support
 - libkvm