Re: [Xen-devel] [PATCH v2 3/3] xen/arm: errata 766422: decode thumb store during data abort

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-07-30 at 18:37 +0100, Julien Grall wrote:
> On 07/29/2013 04:15 PM, Ian Campbell wrote:
> > On Thu, 2013-07-25 at 16:21 +0100, Julien Grall wrote:

> >> +        /* Retrieve the transfer register from the instruction */
> >> +        if ( dabt.len )
> >> +            /* With 32-bit store instruction, the register is in [12..15] 
> >> */
> >> +            info.dabt.reg = (instr & 0xf000) >> 12;
> >> +        else
> >> +            /* With 16-bit store instruction, the register is in [0..3] */
> >> +            info.dabt.reg = instr & 0x7;
> > 
> > Encoding T2 (store via imm8 offset from sp) has it in 8..10.
> 
> Right but ... from ARM DDI 0406C.b B3-1432: an instruction is valid if
> it "is not using the PC as its destination register". So this
> instruction is consider as invalid and will go to "bad_data_abort".

I'm not sure what this has to do with the encoding I pointed to.

A8.8.203 STR (immediate, Thumb), Encoding T2:
        STR<c> <Rt>, [SP, #<imm>]
is:
        1001 0ttt mmmm mmmm (ttt=Rt, mmmm mmmm=imm)

So Rt is in bits 8..10 which != 0..3 which is all you handle above. I
can't see any reason why you wouldn't need to handle this case, it is
certainly a valid instruction.

I think it would be safest to explicitly check for known opcode patterns
and handle those while logging any which we don't recognise. This might
be doable with a lookup table but it may be too sparse. If we were doing
a more full featured instruction decoder then it might be worth it, not
sure about this very specific case.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel