[Top] [All Lists]

Re: [PATCH 1/2] MIPS: Loongson, add sync before target of branch between

To: Yunqiang Su <>, YunQiang Su <>, "" <>
Subject: Re: [PATCH 1/2] MIPS: Loongson, add sync before target of branch between llsc
From: Paul Burton <>
Date: Thu, 10 Jan 2019 17:35:53 +0000
Accept-language: en-US
Authentication-results: spf=none (sender IP is );
Cc: Paul Burton <>, "" <>, "" <>, "" <>, "" <>, "" <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-wavecomp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ri++eyPjk2IgWeoZU7veDkwIWwiUofCProjuvt4K3hM=; b=OeAzXElsdPMYaJff4z15j4CpGq/RgGybGa+Wtz1m5I2halPL8/JjssUWzBAU6+NgTaALxmj+pxt3TaTSl/Y+fxgq34pEvbgYrn2ZfXbH0wpgc4b5+qQO/TIDyVR5hglv1/WpCjVCbBCV8R4KECpJGMybaoAeZgi65bX+xV1wY/w=
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <20190109220844.qk5ufkzjmfwxe5aq@pburton-laptop> <>
Spamdiagnosticmetadata: NSPM
Spamdiagnosticoutput: 1:99
Thread-index: AQHUpQeBAWrYYUkmtUGq4PuZ5oHDz6WnhbYAgABAXoCAAQW6AA==
Thread-topic: [PATCH 1/2] MIPS: Loongson, add sync before target of branch between llsc
User-agent: NeoMutt/20180716
Hi Yunqiang,

On Wed, Jan 09, 2019 at 05:59:07PM -0800, Yunqiang Su wrote:
> > 在 2019年1月10日,上午6:08,Paul Burton <> 写道:
> > On Sat, Jan 05, 2019 at 11:00:36PM +0800, YunQiang Su wrote:
> >> Loongson 2G/2H/3A/3B is quite weak sync'ed. If there is a branch,
> >> and the target is not in the scope of ll/sc or lld/scd, a sync is
> >> needed at the postion of target.
> > 
> > OK, so is this the same issue that the second patch in the series is
> > working around or a different one?
> > 
> > I'm pretty confused at this point about what the actual bugs are in
> > these various Loongson CPUs. Could someone provide an actual errata
> > writeup describing the bugs in detail?
> > 
> > What does "in the scope of ll/sc" mean?
> Loongson 3 series has some version, called, 1000, 2000, and 3000.
> There are 2 bugs all about LL/SC. Let’s call them bug-1 and bug-2.
> BUG-1:  a `sync’ is needed before LL or LLD instruction.
>               This bug appears on 1000 only, and I am sure that it has been 
> fixed in 3000.
> BUG-2: if there is an branch instruction inside LL/SC, and the branch target 
> is outside
>              of the scope of LL/SC, a `sync’ is needed at the branch target.
>              Aka, the first insn of the target branch should be `sync’.
>              Loongson said that, we don’t plan fix this problem in short time 
> before they
>              Designe a totally new core.
> > What happens if a branch target is not "in the scope of ll/sc”?
> At least they said that there won’t be a problem

You still didn't define what "in the scope of ll/sc" means - I'm
guessing that you're referring to a branch target as "in scope" if it is
in between the ll & sc instructions (inclusive?). But this is just a
guess & clarity from people who actually know would be helpful.

And there must be a problem. The whole point of this is that there's a
bug, right? If there's no problem then we don't need to do anything :)

From a look at the GCC patch it talks about placing a sync at a branch
target if it *is* in between an ll & sc [1], which I just can't
reconcile with the phrase "outside of the scope of LL/SC". Is the
problem when a branch target *is* in between an ll & sc, or when it *is
not* between an ll & sc?

Reading this kernel patch doesn't make it any clearer - for example the
sync it emits in build_loongson3_tlb_refill_handler() is nowhere near an
ll or sc instruction. Something doesn't add up here.

> > How does the sync help?
> > 
> > Are jumps affected, or just branches?
> I am not sure, so CC a Loongson people.
> @Paul Hua

Hi Paul - any help obtaining a detailed description of these bugs would
be much appreciated. Even if you only have something in Chinese I can
probably get someone to help translate.

> > Does this affect userland as well as the kernel?
> There is few place can trigger these 2 bugs in kernel.
> In user land we have to workaround in binutils:  
> In fact the kernel is the easiest since we can have a flavor build for 
> Loongson.

My concern with regards to userland is that there's talk of a "deadlock"
- if userland can hit this & the CPU actually stalls then the system is
hopelessly vulnerable to denial of service from a malicious or buggy
userland program, or simply an innocent program unaware of the errata.

> > ...and probably more questions depending upon the answers to these ones.
> > 
> >> Loongson doesn't plan to fix this problem in future, so we add the
> >> sync here for any condition.
> > 
> > So are you saying that future Loongson CPUs will all be buggy too, and
> > someone there has said that they consider this to be OK..? I really
> > really hope that is not true.
> Bug is bug. It is not OK.
> I blame these Loongson guys here.
> Some Loongson guys is not so normal people.
> Anyway they are a little more normal now, and anyway again, still abnormal.
> > If hardware people say they're not going to fix their bugs then working
> > around them is definitely not going to be a priority. It's one thing if
> > a CPU designer says "oops, my bad, work around this & I'll fix it next
> > time". It's quite another for them to say they're not interested in
> > fixing their bugs at all.
> They have interests, while I guess the true reason is that they have no enough
> people and money to desgin a core, while this bug is quilt hard to fix.

I'm not sure I fully understand what you're saying above, but
essentially I want to know that Loongson care about fixing their CPU
bugs. If they don't, and the bugs are as bad as they sound, then in my
view working around them will only reinforce that producing CPUs with
such serious bugs is a good idea.

So if anyone from Loongson is reading, I'd really like to hear that the
above is a miscommunication & that you're not intending to knowingly
design any further CPUs with these bugs.


    ("Loongson3 need a sync before branch target that between ll and sc.")
<Prev in Thread] Current Thread [Next in Thread>