id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	field_blocks	field_dependson	field_seealso
607	Nested traps should probably lower GL too to avoid register corruption	Jakub Jermář	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."	defect	new	major		helenos/kernel/sparc64	mainline		sun4v	rimskyp@…