Re: [PATCH] MIPS: MSA: misaligned support

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

On 18/03/15 23:25, Leonid Yegoshin wrote:
> On 03/18/2015 03:12 PM, James Hogan wrote:
>> Hi Leonid,
>>
>> On Wed, Mar 18, 2015 at 12:46:51PM -0700, Leonid Yegoshin wrote:
>>
>>> thread_msa_context_live() == check of TIF_MSA_CTX_LIVE == existence of
>>> MSA context for thread.
>>> It differs from MSA is owned by thread, it just says that thread has
>>> already initialized MSA.
>>>
>>> Unfortunate choice of function name, I believe.
>> Right (I mis-read when its cleared when i grepped). Still, that would
>> make it even harder to hit since lose_fpu wouldn't clear it, and you
>> already would've taken an MSA disabled exception first.
> No, lose_fpu disables MSA now, saves MSA context and switches off
> TIF_USEDMSA. See 33c771ba5c5d067f85a5a6c4b11047219b5b8f4e, "MIPS:
> save/disable MSA in lose_fpu".
> 
> However, a process still has MSA context initialized and it is indicated
> by TIF_MSA_CTX_LIVE.
> It should have it before it can get any AdE exception on MSA instruction.

Yes, exactly.

> 
>>
>> Anyway, my point was that there's nothing invalid about an unaligned
>> load being the first MSA instruction. You might use it to load the
>> initial vector state.
> 
> No, it is invalid. If MSA is disabled it should trigger "MSA Disabled"
> exception.

It's valid for the user to start their program with a ld.b.
As you say, it'll raise an MSA disabled exception first though. The
handler will own MSA, and set TIF_MSA_CTX_LIVE, which makes the check
pointless?

I suppose an AdE from a normal unaligned load could still race with
another thread modifying the instruction to an MSA ld.b, but even if it
did, I don't think it would do any harm?

> 
> Unfortunately, some HW versions had AdE first and it may be logical from
> some HW point (if access is done before instruction is completely
> decoded). But that is wrong.

Yes, MSA Disabled would clearly come under "Instruction Validity
Exceptions", which is very sensibly higher priority than "Address error
- Data access".

Anyway, at the very least it needs a comment to justify what it is
trying to catch and what harm it is trying to avoid, since it isn't
obvious, and tbh seems pointless.

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]