Re: [PATCH v1 8/9] target-arm: A64: Create Instruction Syndromes for Data Aborts

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Thu, Feb 18, 2016 at 11:42:17AM +0000, Peter Maydell wrote:
> On 18 February 2016 at 09:56, Edgar E. Iglesias
> <edgar.iglesias@gmail.com> wrote:
> > On Tue, Feb 16, 2016 at 07:13:32PM +0000, Peter Maydell wrote:
> >> I think this patch also would be simpler if the encoded info
> >> put in with the TBs was just the syndrome register, rather
> >> than some other encoding.
> >
> > My first try was to only pass the bits needed for the iss
> > (i.e not the full data abort syndrome). We don't have all
> > the info needed at translation time to create the full
> > syndrome (e.g stage2 trap? stage2 trap while stage1 PTW, etc).
> >
> > But we could maybe create as much of the data abort syndrome
> > as possible at translation time and then have the exception
> > handling code add the missing bits. We can then pass the
> > preliminary syndrome from translation time to exception time
> > in the std syndrome format. I can have a look and see what I
> > can do if that makes more sense.
> 
> Yep, that was basically what I had in mind.
> 
> Am I right in thinking that at translate time we capture:
>  IL ISV SAS SSE SRT SF AR
> and then at exception time we determine:
>  EC FnV EA CM S1PTW WnR DFSC
> ?

Yes. It gets a little messy due to the need to the clearing
of ISV (and related fields) and thus setting IL, if the abort
does not target EL2 but it's not too bad.

> 
> In that case I think you could reasonably have the info stored
> with the TBs be "template syndrome >> 14" (since bits [13:0] are
> all info determined at exception-time). The only reason for doing
> this is that the encoded data is stored as sleb128 deltas between
> lines so keeping the values numerically smaller should make them
> take up a bit less space. (I have no idea how significant the
> space saving would be.)
> 
> You should then be able to just have restore_state_to_opc()
> write straight to env->exception.syndrome rather than needing
> a new field in the cpu state.

Sounds good!

Thanks!
Edgar