Module Name: src Committed By: palle Date: Mon Feb 22 10:30:57 UTC 2021
Modified Files: src/sys/arch/sparc64/doc: TODO Log Message: sun4v: update current status of sun4v To generate a diff of this commit: cvs rdiff -u -r1.33 -r1.34 src/sys/arch/sparc64/doc/TODO Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Modified files: Index: src/sys/arch/sparc64/doc/TODO diff -u src/sys/arch/sparc64/doc/TODO:1.33 src/sys/arch/sparc64/doc/TODO:1.34 --- src/sys/arch/sparc64/doc/TODO:1.33 Sun Feb 14 20:30:31 2021 +++ src/sys/arch/sparc64/doc/TODO Mon Feb 22 10:30:57 2021 @@ -1,4 +1,4 @@ -/* $NetBSD: TODO,v 1.33 2021/02/14 20:30:31 palle Exp $ */ +/* $NetBSD: TODO,v 1.34 2021/02/22 10:30:57 palle Exp $ */ Things to be done: @@ -11,23 +11,14 @@ sun4u: - GENERIC.UP kernel hangs on v445 (missing interrupt?) sun4v: - - current status (verified on T5 ldom with 2 VCPU and 4GB): - 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... - Status on T2000 ldom with 8 VCPU and 4GB is that is crashes in /sbin/init doing an access() call where %o0 is corrupted (zero) + - current status + T5 ldom with 2 VCPU and 4GB: + The kernel boots and starts userland when booting miniroot.fs. + The sysinst tool starts properly and requests terminal type. + Upon entering characters on the console, a crash occurs inside + OpenBoot (properly trashed registers). + T2000 ldom with 8 VCPU and 4GB: + On this platform it crashes in /sbin/init doing an access() call where %o0 is corrupted (zero) - 64-bit kernel support - 32-bit kernel support - libkvm