Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

+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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Marc Zyngier]

Hi Hanjun,

On 2019-11-19 01:13, Hanjun Guo wrote:
> +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.

It could work, but it needs to come with the strongest guarantees that
all the DVM agents in the system understand this type of invalidation,
specially as we move into the SVM territory. It may also need to cope
with non-compliant agents being hot-plugged, or at least discovered 
late.

I also wonder if the ARMv8.4-TTL extension (which I have patches for in
the nested virt series) requires the same kind of treatment (after all,
it has an implicit range based on the base granule size and level).

In any way, this requires careful specification, and I don't think
we can improvise this on the ML... ;-)

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

Hi Marc,

On 2019/11/19 18:03, Marc Zyngier wrote:
> Hi Hanjun,
> 
> On 2019-11-19 01:13, Hanjun Guo wrote:
>> +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.
> 
> It could work, but it needs to come with the strongest guarantees that
> all the DVM agents in the system understand this type of invalidation,
> specially as we move into the SVM territory. It may also need to cope
> with non-compliant agents being hot-plugged, or at least discovered late.

Totally agreed, we are working on this in the system level including SMMU.

> 
> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
> the nested virt series) requires the same kind of treatment (after all,
> it has an implicit range based on the base granule size and level).
> 
> In any way, this requires careful specification, and I don't think
> we can improvise this on the ML... ;-)

Sure :), the good news is that ARM officially announced will be
working with Huawei again.

So if I understand your point correctly, we need steps to take:
 - ARM spec needs to make TIBi by range crystal clear and being
   written down in the spec;
 - Firmware description of supporting TLBi by range in system level
   for both FDT and ACPI;
 - Then upstream the code.

Thanks
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Will Deacon]

On Tue, Nov 19, 2019 at 10:03:34AM +0000, Marc Zyngier wrote:
> On 2019-11-19 01:13, Hanjun Guo wrote:
> > 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.
> 
> It could work, but it needs to come with the strongest guarantees that
> all the DVM agents in the system understand this type of invalidation,
> specially as we move into the SVM territory. It may also need to cope
> with non-compliant agents being hot-plugged, or at least discovered late.
> 
> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
> the nested virt series) requires the same kind of treatment (after all,
> it has an implicit range based on the base granule size and level).

It would be good to get confirmation from Arm about this, since the TTL
extension doesn't have the dangerous 'Note' that the range ops do and it
wouldn't be difficult to ignore those bits in hardware where the system
doesn't support the hint for all agents (in comparison to upgrading range
ops to ALL, which may be unpalatable).

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

Hi ARM folks,

On 2019/11/20 9:29, Hanjun Guo wrote:
>>
>> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
>> the nested virt series) requires the same kind of treatment (after all,
>> it has an implicit range based on the base granule size and level).
>>
>> In any way, this requires careful specification, and I don't think
>> we can improvise this on the ML... ;-)
> 
> Sure :), the good news is that ARM officially announced will be
> working with Huawei again.
> 
> So if I understand your point correctly, we need steps to take:
>   - ARM spec needs to make TIBi by range crystal clear and being
>     written down in the spec;
>   - Firmware description of supporting TLBi by range in system level
>     for both FDT and ACPI;
>   - Then upstream the code.

Do we have update here? I noticed that the TLBI by rang for SMMU is
merged for upstream from Rob, any plan or progress for the CPU side?

Sorry to ping you on the mailling list, our upcoming new chip has
this feature and it's good to enable it, so it's a bit urgent for us.

Best regards,
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Will Deacon]

On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
> On 2019/11/20 9:29, Hanjun Guo wrote:
> > > 
> > > I also wonder if the ARMv8.4-TTL extension (which I have patches for in
> > > the nested virt series) requires the same kind of treatment (after all,
> > > it has an implicit range based on the base granule size and level).
> > > 
> > > In any way, this requires careful specification, and I don't think
> > > we can improvise this on the ML... ;-)
> > 
> > Sure :), the good news is that ARM officially announced will be
> > working with Huawei again.
> > 
> > So if I understand your point correctly, we need steps to take:
> >   - ARM spec needs to make TIBi by range crystal clear and being
> >     written down in the spec;
> >   - Firmware description of supporting TLBi by range in system level
> >     for both FDT and ACPI;
> >   - Then upstream the code.
> 
> Do we have update here? I noticed that the TLBI by rang for SMMU is
> merged for upstream from Rob, any plan or progress for the CPU side?
> 
> Sorry to ping you on the mailling list, our upcoming new chip has
> this feature and it's good to enable it, so it's a bit urgent for us.

Have you tried look at the latest version of the patches rather than
"pinging" old history? We're also in the merge window at the moment, so
please cut us some slack.

I also fail to see the urgency. This thing is a pure performance play, and a
fairly niche one at that. I'm not especially comfortable ripping up our TLBI
code without being able to test it.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Will Deacon]

On Fri, Apr 10, 2020 at 12:54:46PM +0100, Will Deacon wrote:
> On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
> > On 2019/11/20 9:29, Hanjun Guo wrote:
> > > > 
> > > > I also wonder if the ARMv8.4-TTL extension (which I have patches for in
> > > > the nested virt series) requires the same kind of treatment (after all,
> > > > it has an implicit range based on the base granule size and level).
> > > > 
> > > > In any way, this requires careful specification, and I don't think
> > > > we can improvise this on the ML... ;-)
> > > 
> > > Sure :), the good news is that ARM officially announced will be
> > > working with Huawei again.
> > > 
> > > So if I understand your point correctly, we need steps to take:
> > >   - ARM spec needs to make TIBi by range crystal clear and being
> > >     written down in the spec;
> > >   - Firmware description of supporting TLBi by range in system level
> > >     for both FDT and ACPI;
> > >   - Then upstream the code.
> > 
> > Do we have update here? I noticed that the TLBI by rang for SMMU is
> > merged for upstream from Rob, any plan or progress for the CPU side?
> > 
> > Sorry to ping you on the mailling list, our upcoming new chip has
> > this feature and it's good to enable it, so it's a bit urgent for us.
> 
> Have you tried look at the latest version of the patches rather than
> "pinging" old history? We're also in the merge window at the moment, so
> please cut us some slack.
> 
> I also fail to see the urgency. This thing is a pure performance play, and a
> fairly niche one at that. I'm not especially comfortable ripping up our TLBI
> code without being able to test it.

Argh, so while it *is* the middle of the merge window and I do fail to see
the urgency of this, I also mixed it up with the TTL series, which is the one
I'm really worried about.

Please post a v3 at -rc1.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

Hi Will,

On 2020/4/10 19:54, Will Deacon wrote:
> On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
>> On 2019/11/20 9:29, Hanjun Guo wrote:
>>>>
>>>> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
>>>> the nested virt series) requires the same kind of treatment (after all,
>>>> it has an implicit range based on the base granule size and level).
>>>>
>>>> In any way, this requires careful specification, and I don't think
>>>> we can improvise this on the ML... ;-)
>>>
>>> Sure :), the good news is that ARM officially announced will be
>>> working with Huawei again.
>>>
>>> So if I understand your point correctly, we need steps to take:
>>>    - ARM spec needs to make TIBi by range crystal clear and being
>>>      written down in the spec;
>>>    - Firmware description of supporting TLBi by range in system level
>>>      for both FDT and ACPI;
>>>    - Then upstream the code.
>>
>> Do we have update here? I noticed that the TLBI by rang for SMMU is
>> merged for upstream from Rob, any plan or progress for the CPU side?
>>
>> Sorry to ping you on the mailling list, our upcoming new chip has
>> this feature and it's good to enable it, so it's a bit urgent for us.
> 
> Have you tried look at the latest version of the patches rather than
> "pinging" old history? We're also in the merge window at the moment, so
> please cut us some slack.

Sorry, I think I missed something, do you mean the patch set for TTL
from Zhenyu?

> 
> I also fail to see the urgency. This thing is a pure performance play, and a
> fairly niche one at that. I'm not especially comfortable ripping up our TLBI
> code without being able to test it.

As discussed before, if it needs the ACPI spec update, it will take
much longer time to get it enabled in mainline kernel, that's the
"urgency", not to ask for merging this patch for this merge window.

Thanks
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

On 2020/4/10 20:02, Will Deacon wrote:
> On Fri, Apr 10, 2020 at 12:54:46PM +0100, Will Deacon wrote:
>> On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
>>> On 2019/11/20 9:29, Hanjun Guo wrote:
>>>>>
>>>>> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
>>>>> the nested virt series) requires the same kind of treatment (after all,
>>>>> it has an implicit range based on the base granule size and level).
>>>>>
>>>>> In any way, this requires careful specification, and I don't think
>>>>> we can improvise this on the ML... ;-)
>>>>
>>>> Sure :), the good news is that ARM officially announced will be
>>>> working with Huawei again.
>>>>
>>>> So if I understand your point correctly, we need steps to take:
>>>>    - ARM spec needs to make TIBi by range crystal clear and being
>>>>      written down in the spec;
>>>>    - Firmware description of supporting TLBi by range in system level
>>>>      for both FDT and ACPI;
>>>>    - Then upstream the code.
>>>
>>> Do we have update here? I noticed that the TLBI by rang for SMMU is
>>> merged for upstream from Rob, any plan or progress for the CPU side?
>>>
>>> Sorry to ping you on the mailling list, our upcoming new chip has
>>> this feature and it's good to enable it, so it's a bit urgent for us.
>>
>> Have you tried look at the latest version of the patches rather than
>> "pinging" old history? We're also in the merge window at the moment, so
>> please cut us some slack.
>>
>> I also fail to see the urgency. This thing is a pure performance play, and a
>> fairly niche one at that. I'm not especially comfortable ripping up our TLBI
>> code without being able to test it.
> 
> Argh, so while it *is* the middle of the merge window and I do fail to see
> the urgency of this, I also mixed it up with the TTL series, which is the one
> I'm really worried about.
> 
> Please post a v3 at -rc1.

A bit lost here, do you mean the TLBi by range patch or the TTL series?

Thanks
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Will Deacon]

On Sat, Apr 11, 2020 at 02:39:13PM +0800, Hanjun Guo wrote:
> On 2020/4/10 20:02, Will Deacon wrote:
> > On Fri, Apr 10, 2020 at 12:54:46PM +0100, Will Deacon wrote:
> > > On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
> > > > On 2019/11/20 9:29, Hanjun Guo wrote:
> > > > > > 
> > > > > > I also wonder if the ARMv8.4-TTL extension (which I have patches for in
> > > > > > the nested virt series) requires the same kind of treatment (after all,
> > > > > > it has an implicit range based on the base granule size and level).
> > > > > > 
> > > > > > In any way, this requires careful specification, and I don't think
> > > > > > we can improvise this on the ML... ;-)
> > > > > 
> > > > > Sure :), the good news is that ARM officially announced will be
> > > > > working with Huawei again.
> > > > > 
> > > > > So if I understand your point correctly, we need steps to take:
> > > > >    - ARM spec needs to make TIBi by range crystal clear and being
> > > > >      written down in the spec;
> > > > >    - Firmware description of supporting TLBi by range in system level
> > > > >      for both FDT and ACPI;
> > > > >    - Then upstream the code.
> > > > 
> > > > Do we have update here? I noticed that the TLBI by rang for SMMU is
> > > > merged for upstream from Rob, any plan or progress for the CPU side?
> > > > 
> > > > Sorry to ping you on the mailling list, our upcoming new chip has
> > > > this feature and it's good to enable it, so it's a bit urgent for us.
> > > 
> > > Have you tried look at the latest version of the patches rather than
> > > "pinging" old history? We're also in the merge window at the moment, so
> > > please cut us some slack.
> > > 
> > > I also fail to see the urgency. This thing is a pure performance play, and a
> > > fairly niche one at that. I'm not especially comfortable ripping up our TLBI
> > > code without being able to test it.
> > 
> > Argh, so while it *is* the middle of the merge window and I do fail to see
> > the urgency of this, I also mixed it up with the TTL series, which is the one
> > I'm really worried about.
> > 
> > Please post a v3 at -rc1.
> 
> A bit lost here, do you mean the TLBi by range patch or the TTL series?

I'm worried about the TTL series without being able to test it.
Please post a v3 of the TLBI by range patch again when you get a chance.

Sorry for the confusion, I got mixed up between the two series.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Hanjun Guo]

On 2020/4/14 15:08, Will Deacon wrote:
> On Sat, Apr 11, 2020 at 02:39:13PM +0800, Hanjun Guo wrote:
>> On 2020/4/10 20:02, Will Deacon wrote:
>>> On Fri, Apr 10, 2020 at 12:54:46PM +0100, Will Deacon wrote:
>>>> On Fri, Apr 10, 2020 at 09:43:49AM +0800, Hanjun Guo wrote:
>>>>> On 2019/11/20 9:29, Hanjun Guo wrote:
>>>>>>>
>>>>>>> I also wonder if the ARMv8.4-TTL extension (which I have patches for in
>>>>>>> the nested virt series) requires the same kind of treatment (after all,
>>>>>>> it has an implicit range based on the base granule size and level).
>>>>>>>
>>>>>>> In any way, this requires careful specification, and I don't think
>>>>>>> we can improvise this on the ML... ;-)
>>>>>>
>>>>>> Sure :), the good news is that ARM officially announced will be
>>>>>> working with Huawei again.
>>>>>>
>>>>>> So if I understand your point correctly, we need steps to take:
>>>>>>     - ARM spec needs to make TIBi by range crystal clear and being
>>>>>>       written down in the spec;
>>>>>>     - Firmware description of supporting TLBi by range in system level
>>>>>>       for both FDT and ACPI;
>>>>>>     - Then upstream the code.
>>>>>
>>>>> Do we have update here? I noticed that the TLBI by rang for SMMU is
>>>>> merged for upstream from Rob, any plan or progress for the CPU side?
>>>>>
>>>>> Sorry to ping you on the mailling list, our upcoming new chip has
>>>>> this feature and it's good to enable it, so it's a bit urgent for us.
>>>>
>>>> Have you tried look at the latest version of the patches rather than
>>>> "pinging" old history? We're also in the merge window at the moment, so
>>>> please cut us some slack.
>>>>
>>>> I also fail to see the urgency. This thing is a pure performance play, and a
>>>> fairly niche one at that. I'm not especially comfortable ripping up our TLBI
>>>> code without being able to test it.
>>>
>>> Argh, so while it *is* the middle of the merge window and I do fail to see
>>> the urgency of this, I also mixed it up with the TTL series, which is the one
>>> I'm really worried about.
>>>
>>> Please post a v3 at -rc1.
>>
>> A bit lost here, do you mean the TLBi by range patch or the TTL series?
> 
> I'm worried about the TTL series without being able to test it.
> Please post a v3 of the TLBI by range patch again when you get a chance.

Thanks, Zhenyu will do that as he is the author of this patch.

Regards,
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH v2] arm64: cpufeatures: add support for tlbi range instructions

[Zhenyu Ye]

Hi Will,

On 2020/4/14 15:08, Will Deacon wrote:
> 
> I'm worried about the TTL series without being able to test it.
> Please post a v3 of the TLBI by range patch again when you get a chance.
> 

I have sent the v3 of the TLBI RANGE patch based on Linux 5.7-rc1:

https://lore.kernel.org/linux-arm-kernel/20200414112835.1121-1-yezhenyu2@huawei.com/


As for the TTL series, it's based on commit "a6d60245d6", which has tracked
the levels of the page tables have been cleared, so I think there is no
problem at the software level. (The stride parameter of __flush_tlb_range in
ARM64 also depends on the values of cleared_*, and behaves well)

If we want to test whether the hardware deals with TTL correctly, I have a
vague idea:

1. mmap a piece of memory;
2. write our own change_protection_range(), in which calls the tlbi
   interface with TTL value;
3. if the hardware deals with TTL correctly, the permissions of memory
   should have changed, otherwise not.


Thanks,
Zhenyu



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel