Re: [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers

[Joshua Kinard]

On 06/05/2015 09:10, Ralf Baechle wrote:
> On Mon, Jun 01, 2015 at 05:09:34PM -0700, Leonid Yegoshin wrote:
> 
> Leonid,
> 
> to me the biggest technical problem with this patch is that the new Kconfig
> option is user visible.  This is the kind of deeply technical options
> which exceeds the technical knowledge of most users, so it should probably
> be driven by a select.
> 
> We probably also want to enquire how old CPUs from before the invention
> of the stype field are behaving.  If those as I hope for all treat an
> stype != 0 as stype 0 we could simply drop the option.  But we might
> simply be out of luck - dunno.
> 
> Maciej,
> 
> do you have an R4000 / R4600 / R5000 / R7000 / SiByte system at hand to
> test this?  I think we don't need to test that SYNC actually works as
> intended but the simpler test that SYNC <stype != 0> is not causing a
> illegal instruction exception is sufficient, that is if something like
> 
> int main(int argc, charg *argv[])
> {
> 	asm("	.set	mips2		\n"
> 	"	sync	0x10		\n"
> 	"	sync	0x13		\n"
> 	"	sync	0x04		\n"
> 	"	.set	mips 0		\n");
> 
> 	return 0;
> }
> 
> doesn't crash we should be ok.
> 
> The kernel's SYNC emulation should already be ok.  We ignore the stype
> field entirely and for a uniprocessor R2000/R3000 that should be just
> the right thing.
> 
>   Ralf

I tried just compiling this on my SGI O2, which has an RM7000 CPU, and it is
refusing to even compile (after fixing typos):

# gcc -O2 -pipe sync_test.c -o sync_test
{standard input}: Assembler messages:
{standard input}:19: Error: invalid operands `sync 0x10'
{standard input}:20: Error: invalid operands `sync 0x13'
{standard input}:21: Error: invalid operands `sync 0x04'

So a bit of searching landed me here:
http://stackoverflow.com/questions/3599564/gnu-assembler-for-mips-how-to-emit-sync-instructions

And I recoded the sync insns like this:

int main(int argc, char *argv[])
{
	__asm__ volatile (      \
	"	.set    mips2				\n"
	"	.word (0x0000000f | (0x10 << 6))	\n"
	"	.word (0x0000000f | (0x14 << 6))	\n"
	"	.word (0x0000000f | (0x04 << 6))	\n"
	"	.set    mips0				\n"
	);

	return 0;
}

And the program compiles successfully and executes with no noticeable oddities
or errors.  Nothing in dmesg, no crashes, booms, or disappearance of small
kittens.  I did a quick disassembly to make sure all three got emitted:

004005e0 <main>:
  4005e0:       27bdfff8        addiu   sp,sp,-8
  4005e4:       afbe0004        sw      s8,4(sp)
  4005e8:       03a0f021        move    s8,sp
  4005ec:       afc40008        sw      a0,8(s8)
  4005f0:       afc5000c        sw      a1,12(s8)
> 4005f4:       0000040f        sync.p
> 4005f8:       0000050f        0x50f
> 4005fc:       0000010f        0x10f
  400600:       00001021        move    v0,zero


Same effect on my Octane (IP30) w/ an R14000 CPU.  Tested inside a uclibc-based
chroot, but no change.  Executes successfully silently.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@xxxxxxxxxx
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic