[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c9dfb341-9d14-1a62-0c34-6ec8bd9b4c55@huawei.com>
Date: Tue, 19 Nov 2019 09:13:17 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: Marc Zyngier <maz@...nel.org>, Zhenyu Ye <yezhenyu2@...wei.com>
CC: Will Deacon <will@...nel.org>, <catalin.marinas@....com>,
<suzuki.poulose@....com>, <mark.rutland@....com>,
<tangnianyao@...wei.com>, <xiexiangyou@...wei.com>,
<linux-kernel@...r.kernel.org>, <arm@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linuxarm <linuxarm@...wei.com>,
Shaokun Zhang <zhangshaokun@...ilicon.com>,
wanghuiqiang <wanghuiqiang@...wei.com>
Subject: Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range
instructions
+Cc linux-arm-kernel mailing list and Shaokun.
Hi Marc,
On 2019/11/11 22:04, Marc Zyngier wrote:
> On 2019-11-11 14:56, Zhenyu Ye wrote:
>> On 2019/11/11 21:27, Will Deacon wrote:
>>> On Mon, Nov 11, 2019 at 09:23:55PM +0800, Zhenyu Ye wrote:
[...]
>>>
>>> How does this address my concerns here:
>>>
>>>
>>> https://lore.kernel.org/linux-arm-kernel/20191031131649.GB27196@willie-the-truck/
>>>
>>> ?
>>>
>>> Will
>>
>> I think your concern is more about the hardware level, and we can do
>> nothing about
>> this at all. The interconnect/DVM implementation is not exposed to
>> software layer
>> (and no need), and may should be constrained at hardware level.
>
> You're missing the point here: the instruction may be implemented
> and perfectly working at the CPU level, and yet not carried over
> the interconnect. In this situation, other CPUs may not observe
> the DVM messages instructing them of such invalidation, and you'll end
> up with memory corruption.
>
> So, in the absence of an architectural guarantee that range invalidation
> is supported and observed by all the DVM agents in the system, there must
> be a firmware description for it on which the kernel can rely.
I'm thinking of how to add a firmware description for it, how about this:
Adding a system level flag to indicate the supporting of TIBi by range,
which means adding a binding name for example "tlbi-by-range" at system
level in the dts file, or a tlbi by range flag in ACPI FADT table, then
we use the ID register per-cpu and the system level flag as
if (cpus_have_const_cap(ARM64_HAS_TLBI_BY_RANGE) && system_level_tlbi_by_range)
flush_tlb_by_range()
else
flush_tlb_range()
And this seems work for heterogeneous system (olny parts of the CPU support
TLBi by range) as well, correct me if anything wrong.
Thanks
Hanjun
Powered by blists - more mailing lists