Saving / restoring SPRG[0-3] around OpenFirmware entry

[Jason Thorpe <thorpej%me.com@localhost>]

I’m working on fixing the virtual mode OpenFirmwre client interface so that it will work on my PowerBook6,8, and I’m wondering if anyone knows the origins of this commit by Matt Thomas to powerpc/oea/ofw_subr.S:

----------------------------
revision 1.9
date: 2011-06-12 09:35:10 -0700;  author: matt;  state: Exp;  lines: +46 -44;
Save/restore all sprgs when calling OFW.
Move all-zero variables from .data to .bss
Use .lcomm for local variables.
Cleanup a bit of assembly.
Clear PSL_IP in the saved ofmsr (was previously done in ofwoea_machdep.c)
----------------------------

In particular, the "Save/restore all sprgs when calling OFW.”

This seems totally unnecessary (and, actually, counter-productive), per section 7.1 of the OpenFirmware PowerPC CPU bindings, in particular “Table 1. Register usage conventions”, where is states that for SPRG[0-3], real-mode "client interface shall preserve” and in virtual-mode "client interface shall not modify”.

The reason this is important: in real-mode, it is expected that there won’t be any exceptions that throw you back into the kernel; the MMU is disabled, so no DSI / ISI traps, and interrupts are turned off, too.

<quote>
The term "preserved" below shall mean that the register has the same value when returning as it did when the call was made.
</quote>

…and beyond that the firmware makes no guarantee about the value of SPRG[0-3] while handling a client call.

But, in virtual-mode, the MMU is turned on so we would expect to get DSI / ISI traps; OFW’s translations are subject to eviction from the HTAB just like anyone else’s, and so we need to be able to handle PTE spills.  This is why in virtual-mode, the bindings state that OFW “shall not modify”; if an ISI or DSI trap happens, we’re going to land in the kernel’s exception vectors, and those exception vectors may very well depend on having SPRG[0-3] set up the way the kernel had them (and, certainly, ours do; the current-cpu is stashed away in SPRG0).

Anyway, I was hoping someone might have knowledge of why this change was made.  I can easily experiment with it on my systems, but of course there are lots of PowerPC systems with OFW that I don’t have, and it would be nice to have evidence that saving/restoring SPRG[0-3] fixed an actual bug or if it was merely a misguided attempt at belt-and-suspenders.

-- thorpej