Date: Thu, 8 Dec 2016 10:31:16 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Christopher Covington <cov@codeaurora.org>
Cc: Will Deacon <will.deacon@arm.com>,
        Shanker Donthineni <shankerd@codeaurora.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Andre Przywara <andre.przywara@arm.com>,
        Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>,
        James Morse <james.morse@arm.com>, Andrew Pinski <apinski@cavium.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Geoff Levand <geoff@infradead.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] arm64: Work around Falkor erratum 1003
Message-ID: <20161208103115.GF33075@MBP.local>
References: <20161207200028.4420-1-cov@codeaurora.org>
 <20161207200028.4420-2-cov@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161207200028.4420-2-cov@codeaurora.org>
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1471
Lines: 33

On Wed, Dec 07, 2016 at 03:00:26PM -0500, Christopher Covington wrote:
> From: Shanker Donthineni <shankerd@codeaurora.org>
> 
> On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
> allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
> updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
> separately using a reserved ASID will ensure that there are no TLB entries
> with incorrect ASID after changing the the ASID.
> 
> Pseudo code:
>   write TTBRx_EL1[ASID] to a reserved value
>   ISB
>   write TTBRx_EL1[BADDR] to a desired value
>   ISB
>   write TTBRx_EL1[ASID] to a desired value
>   ISB

While the new ASID probably won't have incorrect TLB entries, the
reserved ASID will have random entries from all over the place. That's
because in step 1 you change the ASID to the reserved one while leaving
the old BADDR in place. There is a brief time before changing the ASID
when speculative page table walks will populate the TLB with entries
tagged with the reserved ASID. Such entries are never removed during TLB
shoot-down for the real ASID, so, depending on how this CPU implements
the walk cache, you could end up with intermediate level entries still
active and pointing to freed/reused pages. It will eventually hit an
entry that looks global with weird consequences.

We've been bitten by this in the past on arm32: 52af9c6cd863 ("ARM:
6943/1: mm: use TTBR1 instead of reserved context ID").

-- 
Catalin