Nested traps should probably lower GL too to avoid register corruption

[Jakub Jermář]

On sun4v, the active set of global registers is determined by the GL (global level) register, similarly to the TL (trap level) register, it will be increased by one when a (nested) trap occurs. The UA2005 architecture defines a maximum value for this register (MAXPGL) and the UltraSPARC T1 processor defines MAXPGL=2. Attempts to store a greater value to GL will result in storing MAXPGL.

Now, when handling a nested trap, HelenOS lowers the TL value to avoid overflowing it and also to support the preemptible_trap handler, but it does not lower the GL value. It seems to me like there is a potential for corrupting some of the global registers at GL=2:

1. executing in uspace: TL=0, GL=0
2. the uspace code executes the SAVE instruction while CANSAVE=0
3. window_spill trap: TL=1, GL=1
4. trying to save the window to the uspace stack, which is not mapped
5. fast_data_access_MMU_miss: TL=2, GL=2
6. need to call preemptible_handler, lower TL: TL=1, GL=2
7. PREEMPTIBLE_HANDLER_USPACE does INLINE_SPILL_TO_WBUF because CANSAVE=0
8. let's assume the wbuf is not mapped by DTLB, so we trap: TL=2, GL=2

At this point, the nested DTLB trap is sharing the globals at GL 2 with the preemptible handler. When the nested trap returns, chances are that some globals will be corrupted.