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

[Fredrik Noring <noring@nocrew.org>]

Hi Maciej,

>  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.

Thanks for your detailed description!

>  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.

Yes, hardware breakpoints and hardware performance counters are very
interesting features to develop after the initial submission.

>  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.

Excellent. I will just drop this patch then.

Fredrik