PowerMac G5's and such: Should HIOR save/restore be involved in ofw_save_trap_vec and ofw_restore_trap_vec?

[Mark Millard]

With the recent discovery that for the IBM970 family
in sys/powerpc/aim/mp_cpudep.c :

                /* Set HIOR to 0 */
                __asm __volatile("mtspr 311,%0" :: "r"(0));
                powerpc_sync();


needed to be in cpudep_ap_early_bootstrap in order to
avoid use of openfirmware's exception/trap handlers
in powerpc64 FreeBSD, there is the question:

For IBM970 family in aim (or at least PowerMac), should
ofw_save_trap_vec and ofw_restore_trap_vec be managing
HIOR instead of copying around vector code that is from
low memory?

This goes along with the modern DMAP address range placement
and what address ranges are invalid vs. valid when
openfirmware_core is in use. Currently (unless usefdt mode
is in use), ofwdump use (such as ofwdump -ap) produces:

timeout stopping cpus
[ thread pid 11 tid 100003 ]
Stopped at      k_trap+0x28:    stdu    r31, r1, 0xfd50
db> bt
Tracing pid 11 tid 100003 td 0xc000000002251000
KDB: reentering
KDB: stack backtrace:
0x000000000119b370: at .kdb_backtrace+0x5c
0x000000000119b4a0: at .kdb_reenter+0x44
0x000000000119b520: at .trap+0x74
0x000000000119b6c0: at .powerpc_interrupt+0x2cc
0x000000000119b760: kernel DSI read trap @ 0xffffffffffb7f400 by .db_backtrace+0x40: srr1=0x9000000000001032
            r1=0x119ba10 cr=0x24001044 xer=0 ctr=0x60cd24 r2=0x1583af0 sr=0x40000000 frame=0x119b790
0x000000000119ba10: at 0x1e95014
0x000000000119baa0: at .db_trace_thread+0x38
0x000000000119bb30: at .db_stack_trace+0x124
0x000000000119bbc0: at .db_command+0x3a8
0x000000000119bcf0: at .db_command_loop+0x74
0x000000000119bd70: at .db_trap+0x138
0x000000000119bef0: at .kdb_trap+0x194
0x000000000119bfc0: at .db_trap_glue+0x94
0x000000000119c040: at dbtrap+0x144
KDB: reentering
KDB: stack backtrace:
. . .

where it turns out that .db_backtrace+0x40 was for
the code:

                /*
                 * Locate the next frame by grabbing the backchain ptr
                 * from frame[0]
                 */
                stackframe = *(db_addr_t *)stackframe;

So, the 0xffffffffffb7f400 seems to possibly be an
openfirmware stack address (backchain pointer) that
FreeBSD seems to be disallowing.

There could be implications of needing to switch how
address ranges are handled as part of ofw_save_trap_vec
and ofw_restore_trap_vec. (At least if ofwdump is to
be supported.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)