Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6e07ad52-2629-346e-6217-ec07777ebc5b@quicinc.com>
Date:   Tue, 11 Jul 2023 11:30:44 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH] arm64: Add the arm64.nolse_atomics command line option
To:     Marc Zyngier <maz@kernel.org>
CC:     <will@kernel.org>, <corbet@lwn.net>, <catalin.marinas@arm.com>,
        <quic_pkondeti@quicinc.com>, <quic_kaushalk@quicinc.com>,
        <quic_satyap@quicinc.com>, <quic_shashim@quicinc.com>,
        <quic_songxue@quicinc.com>, <linux-doc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
References: <20230710055955.36551-1-quic_aiquny@quicinc.com>
 <875y6s8bwb.wl-maz@kernel.org>
 <32f442e3-3d5c-4cec-9791-0da039f88287@quicinc.com>
 <874jmc8654.wl-maz@kernel.org>
From:   "Aiqun(Maria) Yu" <quic_aiquny@quicinc.com>
In-Reply-To: <874jmc8654.wl-maz@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/10/2023 5:31 PM, Marc Zyngier wrote:
> On Mon, 10 Jul 2023 09:19:54 +0100,
> "Aiqun(Maria) Yu" <quic_aiquny@quicinc.com> wrote:
>>
>> On 7/10/2023 3:27 PM, Marc Zyngier wrote:
>>> On Mon, 10 Jul 2023 06:59:55 +0100,
>>> Maria Yu <quic_aiquny@quicinc.com> wrote:
>>>>
>>>> In order to be able to disable lse_atomic even if cpu
>>>> support it, most likely because of memory controller
>>>> cannot deal with the lse atomic instructions, use a
>>>> new idreg override to deal with it.
>>>
>>> In general, the idreg overrides are *not* there to paper over HW bugs.
>>> They are there to force the kernel to use or disable a feature for
>>> performance reason or to guide the *enabling* of a feature, but not
>>> because the HW is broken.
>>>
>>> The broken status of a HW platform must also be documented so that we
>>> know what to expect when we look at, for example, a bad case of memory
>>> corruption (something I'd expect to see on a system that only
>>> partially implements atomic memory operations).
>>>
>>
>> good idea. A noc error would be happened if the lse atomic instruction
>> happened during a memory controller doesn't support lse atomic
>> instructions.
>> I can put the information in next patchset comment message. Pls feel
>> free to let know if there is other place to have this kind of
>> information with.
> 
> For a start, Documentation/arch/arm64/silicon-errata.rst should
> contain an entry for the actual erratum, and a description of the
> symptoms of the issue (you're mentioning a "noc error": how is that
> reported to the CPU?).

This is not a cpu's errata as my understanding. It is the DDR subsystem 
which don't have the LSE atomic feature supported.
> 
> The workaround should also be detected at runtime -- we cannot rely on
> the user to provide a command-line argument to disable an essential
> feature that anyone has taken for granted for most of a decade...

We are also seeking help from DDR Subsystem POC to see whether it is 
possible to detect the LSE atomic feature support or not at runtime.

In my opinion, LSE atomic is a system level feature instead of a cpu 
only feature. So currently solution we is that even if cpu support lse 
atomic, but it still needed to be disabled if the cpu working with a lse 
atomic not support by current system's DDR subsystem.

> 
> [...]
> 
>>>> @@ -185,6 +195,7 @@ static const struct {
>>>>    	{ "arm64.nomops",		"id_aa64isar2.mops=0" },
>>>>    	{ "arm64.nomte",		"id_aa64pfr1.mte=0" },
>>>>    	{ "nokaslr",			"arm64_sw.nokaslr=1" },
>>>> +	{ "arm64.nolse_atomic",         "id_aa64isar0.atomic=0" },
>>>
>>> And what of 32bit?
> 
> This particular question still stands, as it is likely to affect VMs.
> 
> 	M.
> 

-- 
Thx and BRs,
Aiqun(Maria) Yu