* [PATCH] MIPS: Optional SYNC emulation
@ 2020-08-21 3:12 Heiher
2020-09-30 11:16 ` Thomas Bogendoerfer
0 siblings, 1 reply; 4+ messages in thread
From: Heiher @ 2020-08-21 3:12 UTC (permalink / raw)
To: linux-mips
Cc: Jiaxun Yang, Huacai Chen, Paul Burton, Maciej W . Rozycki, Heiher
MIPS ISA defines several types of memory barrier, of which Type-0 (full barrier)
is required, and the others are optional. In some vendor implementation (such as
Loongson), all optional parts are implemented to emit an illegal instruction
exception. Here, emulate to full barrier to ensure the functional semantics.
If an implementation does not support SYNC 0, it should also not support SMP, so
the `smp_mb()` is only a compilation barrier.
Signed-off-by: Heiher <r@hev.cc>
---
arch/mips/kernel/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 38aa07ccdbcc..d63e8671e9d2 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -501,6 +501,7 @@ asmlinkage void do_be(struct pt_regs *regs)
#define RD 0x0000f800
#define FUNC 0x0000003f
#define SYNC 0x0000000f
+#define STYPE 0x000007c0
#define RDHWR 0x0000003b
/* microMIPS definitions */
@@ -688,6 +689,8 @@ static int simulate_rdhwr_mm(struct pt_regs *regs, unsigned int opcode)
static int simulate_sync(struct pt_regs *regs, unsigned int opcode)
{
if ((opcode & OPCODE) == SPEC0 && (opcode & FUNC) == SYNC) {
+ if ((opcode & STYPE) != 0)
+ smp_mb();
perf_sw_event(PERF_COUNT_SW_EMULATION_FAULTS,
1, regs, 0);
return 0;
--
2.28.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] MIPS: Optional SYNC emulation
2020-08-21 3:12 [PATCH] MIPS: Optional SYNC emulation Heiher
@ 2020-09-30 11:16 ` Thomas Bogendoerfer
2020-10-01 7:45 ` Hev
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Bogendoerfer @ 2020-09-30 11:16 UTC (permalink / raw)
To: Heiher
Cc: linux-mips, Jiaxun Yang, Huacai Chen, Paul Burton, Maciej W . Rozycki
On Fri, Aug 21, 2020 at 11:12:28AM +0800, Heiher wrote:
> MIPS ISA defines several types of memory barrier, of which Type-0 (full barrier)
> is required, and the others are optional. In some vendor implementation (such as
> Loongson), all optional parts are implemented to emit an illegal instruction
> exception. Here, emulate to full barrier to ensure the functional semantics.
>
> If an implementation does not support SYNC 0, it should also not support SMP, so
> the `smp_mb()` is only a compilation barrier.
I see your point, but isn't taking an exception already more than a
compiler barrier ? Does the missing sync hurt in real life ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] MIPS: Optional SYNC emulation
2020-09-30 11:16 ` Thomas Bogendoerfer
@ 2020-10-01 7:45 ` Hev
2020-11-02 12:33 ` Maciej W. Rozycki
0 siblings, 1 reply; 4+ messages in thread
From: Hev @ 2020-10-01 7:45 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: linux-mips, Jiaxun Yang, Huacai Chen, Paul Burton, Maciej W . Rozycki
Hello Thomas,
On Wed, Sep 30, 2020 at 8:48 PM Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
>
> On Fri, Aug 21, 2020 at 11:12:28AM +0800, Heiher wrote:
> > MIPS ISA defines several types of memory barrier, of which Type-0 (full barrier)
> > is required, and the others are optional. In some vendor implementation (such as
> > Loongson), all optional parts are implemented to emit an illegal instruction
> > exception. Here, emulate to full barrier to ensure the functional semantics.
> >
> > If an implementation does not support SYNC 0, it should also not support SMP, so
> > the `smp_mb()` is only a compilation barrier.
>
> I see your point, but isn't taking an exception already more than a
> compiler barrier ? Does the missing sync hurt in real life ?
As far as I known, the optional sync instruction has been used in user
space programs (such as firefox), and the illegal instruction
exception does not include the semantics of the memory barrier, so if
the optional sync instruction is not simulated, the memory access
order of these programs it may be different from the order in the
code.
About the compiler barrier, What if the hardware does not support SYNC
0? I think it does not support SMP, so smp_mb() is only a compiler
barrier and will not cause infinite recursion in the simulation.
Thank you
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
--
Best regards!
Hev
https://hev.cc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] MIPS: Optional SYNC emulation
2020-10-01 7:45 ` Hev
@ 2020-11-02 12:33 ` Maciej W. Rozycki
0 siblings, 0 replies; 4+ messages in thread
From: Maciej W. Rozycki @ 2020-11-02 12:33 UTC (permalink / raw)
To: Hev
Cc: Thomas Bogendoerfer, linux-mips, Jiaxun Yang, Huacai Chen, Paul Burton
On Thu, 1 Oct 2020, Hev wrote:
> > I see your point, but isn't taking an exception already more than a
> > compiler barrier ? Does the missing sync hurt in real life ?
>
> As far as I known, the optional sync instruction has been used in user
> space programs (such as firefox), and the illegal instruction
> exception does not include the semantics of the memory barrier, so if
> the optional sync instruction is not simulated, the memory access
> order of these programs it may be different from the order in the
> code.
Your concerns as to ERET not implying any of the SYNC semantics seem
valid to me.
> About the compiler barrier, What if the hardware does not support SYNC
> 0? I think it does not support SMP, so smp_mb() is only a compiler
> barrier and will not cause infinite recursion in the simulation.
However both SYNC 0 is mandatory (save for ancient MIPS I ISA processors)
and other SYNC operations have to fall back to SYNC 0 if not specifically
implemented. Even MIPSr1 had this[1][2]:
"SYNC does not guarantee the order in which instruction fetches are
performed. The stype values 1-31 are reserved for future extensions to
the architecture. A value of zero will always be defined such that it
performs all defined synchronization operations. Non-zero values may be
defined to remove some synchronization operations. As such, software
should never use a non-zero value of the stype field, as this may
inadvertently cause future failures if non-zero values remove
synchronization operations."
and MIPSr0.95 was even stricter[3][4]:
"SYNC does not guarantee the order in which instruction fetches are
performed. The stype values 1-31 are reserved; they produce the same
result as the value zero."
so I suggest a board/CPU-specific workaround.
References:
[1] "MIPS32 Architecture For Programmers, Volume II: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 1.00, August 29, 2002, p. 209
[2] "MIPS64 Architecture For Programmers, Volume II: The MIPS64
Instruction Set", MIPS Technologies, Inc., Document Number: MD00087,
Revision 1.00, August 29, 2002, p. 295
[3] "MIPS32 Architecture For Programmers, Volume II: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 0.95, March 12, 2001, p. 215
[4] "MIPS64 Architecture For Programmers, Volume II: The MIPS64
Instruction Set", MIPS Technologies, Inc., Document Number: MD00087,
Revision 0.95, March 12, 2001, p. 300
HTH,
Maciej
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-11-02 12:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-21 3:12 [PATCH] MIPS: Optional SYNC emulation Heiher
2020-09-30 11:16 ` Thomas Bogendoerfer
2020-10-01 7:45 ` Hev
2020-11-02 12:33 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).