Re: Aw: [RFC] MIPS: R5900: Use mandatory SYNC.L in exception handlers

["Maciej W. Rozycki" <macro@mips.com>]

Jürgen, Fredrik --

> > Would you be able to explain the notes
> > 
> > 	/* In an error exception handler the user space could be uncached. */
> > 
> > in the patch ported from v2.6 below?
> 
> The tx79architecture.pdf says:
> 2.4 kuseg becomes an uncached area when an error exception (Status.ERL = 1) occurs (FLX04)
> 2.4.1 Phenomenon
> There are cases in which kuseg (0x0000_0000 – 0x7FFF_FFFF) becomes uncached in an error exception handler (Status.ERL==1) and data consistency with cached area (kseg, ksseg, kseg0) is lost.
> 2.4.2 Corrective measures
> In an error exception handler (Status.ERL==1), when accessing kuseg (0x0000_0000 – 0x7FFF_FFFF), access it after guarding using SYNC.L as follows:
> SYNC.L
> SW ku seg

 This change makes no sense to me anyway I am afraid.

 At the error level (Status.ERL=1) the user segment becomes unmapped and 
therefore all KUSEG addresses become physical addresses.  Which means that 
if any of this code you have patched is called to access user pages, then 
you have a bigger problem than just the cache going out of sync.

 The only reason to access KUSEG at the error level is to save/restore 
register state to/from a dedicated RAM area offset from $zero so that 
execution is restartable.  Unlike at the exception level you cannot use 
$k0 and $k1 as temporaries, because an error exception can happen any time 
including in particular while $k0 and $k1 are in active use at the 
exception level, so clobbering them would make the system non-restartable 
(of course receiving an error exception may mean that anyway).

 Code to write/read that dedicated area should be purpose-crafted and the 
area won't be accessed at any other time, so the issue of being cache 
coherent or not does not apply as the area will never be accessed with 
caching operations.

 I can see the R5900 has additional classes of error exceptions defined, 
such as debug and performance counter exceptions, which are not related to 
hardware faults and can happen in regular execution in response to certain 
conditions requested.  If you want to handle these implementation specific 
extensions and consequently serve these exceptions, then please take care 
of all the requirements as code to support them is added.

 Though as I wrote above it does not look to me like anything specific 
will be needed -- the handler at entry will save the state necessary for 
restartability to a dedicated RAM area first and then to the kernel stack, 
switch the error level off, do the necessary processing, and then reverse 
the steps before resuming execution interrupted.

  Maciej