[PATCH v2] MIPS: add speculation_barrier support

[Jiaxun Yang]

> 2023年5月3日 22:04，Maciej W. Rozycki <macro@orcam.me.uk> 写道：
> 
> On Wed, 3 May 2023, Richard Sandiford wrote:
> 
>>> speculation_barrier for MIPS needs sync+jr.hb (r2+),
>>> so we implement __speculation_barrier in libgcc, like arm32 does.
>> 
>> Looks reasonable, but do you have a source for the fallback
>> pre-r2 handling?  (Thanks for adding that btw, since I realise
>> it's not your focus here.)
> 
> Seconded WRT legacy MIPS support, really appreciated.

Hi all,

Just my two cents on legacy MIPS support.

Since it’s possible to run R2- binary on R2+ processor, we’d better find a
semantic that do eliminate speculation on all processors. While SSNOPs
on R2+ processors is pretty much undefined, there is no guarantee that
SSNOP sequence can eliminate speculation.

My proposal is for R2- CPUs we can do a dummy syscall to act as instruction
hazard barrier, since exception must clear the pipeline this should be true
for all known implementations.

The most lightweight syscall I know is to do a MIPS_ATOMIC_SET with
sysmips. A dummy variable on stack should do the track. Do let me know if there
is a better option.

I have a vague memory about a discussion finding that exception does not indicate
a memory barrier, so perhaps we still need a sync preceding to that syscall.


> 
> I think there may be no authoritative source of information here, this is 
> a grey area.  The longest SSNOP sequences I have seen were for the various 
> Broadcom implementations and counted 7 instructions.  Both the Linux 
> kernel and the CFE firmware has them.

Was it for SiByte or BMIPS?

> 
> Also we may not be able to fully enforce ordering for the oldest devices 
> that do not implement SYNC, as this is system-specific, e.g. involving 
> branching on the CP0 condition with the BC0F instruction, and inventing an 
> OS interface for that seems unreasonable at this point of history.

I guess this is not a valid concern for user space applications?
As per R4000 manual BC0F will issue “Coprocessor unusable exception”
exception and it’s certain that we have Staus.CU0 = 0 in user space.

BC0F is not mentioned in MIPS-IV and later MIPS specs.

Thanks
Jiaxun

> 
> OTOH Linux emulates any traps on SYNC and even though the handler does 
> nothing beyond decoding the instruction the exception handling overhead 
> ought to make all the effects from before the exception invocation fully 
> visible after its completion.  So for Linux targets I think we ought to 
> just emit SYNC unconditionally; glibc has already relied on it for years 
> now.
> 
> Overall, oh well, I guess we'll have to live with the limitations.
> 
>  Maciej