Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <0f42779799d54d2478a644391096c2d85e494c49.camel@mengyan1223.wang>
Subject: Re: [PATCH V9 05/24] LoongArch: Add build infrastructure
From:   Xi Ruoyao <xry111@mengyan1223.wang>
To:     WANG Xuerui <kernel@xen0n.name>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Arnd Bergmann <arnd@arndb.de>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Airlie <airlied@linux.ie>,
        Jonathan Corbet <corbet@lwn.net>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, Xuefeng Li <lixuefeng@loongson.cn>,
        Yanteng Si <siyanteng@loongson.cn>,
        Huacai Chen <chenhuacai@gmail.com>,
        Guo Ren <guoren@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Sun, 01 May 2022 23:43:32 +0800
In-Reply-To: <3f46aa25-ef45-fff8-dba5-5db1034b38d9@xen0n.name>
References: <20220430090518.3127980-1-chenhuacai@loongson.cn>
         <20220430090518.3127980-6-chenhuacai@loongson.cn>
         <3f46aa25-ef45-fff8-dba5-5db1034b38d9@xen0n.name>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.1 
MIME-Version: 1.0
Precedence: bulk

On Sun, 2022-05-01 at 18:09 +0800, WANG Xuerui wrote:
> > +cflags-y +=3D $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,)
> Unfortunately we're still working around the LL/SC hardware issue even
> after migrating to LoongArch... might be better to add a comment too.=20
> (something along the line of "we work around the issue manually in the
> handwritten assembly, so no automatic workarounds should kick in")

There is no LoongArch assembler which is publicly available and has a -
m(no)?fix-loongson3-llsc option.  The people writing assembly have to
add the workarounds manually.

This line should be removed for a upstream patch.  If you need to
support "unpublic" toolchains with this option, keep it in a seperate
git repo or branch.

Regarding LL/SC workaround, GCC is using a different pattern:

(https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dblob;f=3Dgcc/config/loongarch/syn=
c.md;h=3D0c4f1983;hb=3DHEAD#l132)

 132   return "%G5\\n\\t"
 133          "1:\\n\\t"
 134          "ll.<amo>\\t%0,%1\\n\\t"
 135          "bne\\t%0,%z2,2f\\n\\t"
 136          "or%i3\\t%6,$zero,%3\\n\\t"
 137          "sc.<amo>\\t%6,%1\\n\\t"
 138          "beq\\t$zero,%6,1b\\n\\t"
 139          "b\\t3f\\n\\t"
 140          "2:\\n\\t"
 141          "dbar\\t0x700\\n\\t"
 142          "3:\\n\\t";

Note that the dbar instruction has "hint" 0x700 instead of 0 (using a
special number was proposed by me, so an updated LoongArch
implementation can recognize and ignore this instruction when the
workaround is unneeded).  And the instruction is "skipped" by the
previous "b" instruction.  I guess it's enough to "force" LA464 to
behave correctly for the LL/SC loop w/o really inserting a barrier.

GCC LoongArch port maintainers have not publicly explained the rational
of this pattern, but it works fine in userspace on a 3A5000 processor.=20
Maybe the kernel could also benefit from this "new" pattern but I'm not
sure.  I suggest to discuss this with your compiler team and hardware
team.
--=20
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University