Re: [PATCH v2 2/4] MIPS: Introduce config options for LLSC availability

From: Jiaxun Yang
Date: Fri Jun 21 2024 - 11:22:16 EST




在2024年6月21日六月 下午2:57,Maciej W. Rozycki写道:
> On Fri, 21 Jun 2024, Jiaxun Yang wrote:
>
>> > I think this ought not to be done in two places independently and the
>> > pieces in <asm/mach-*/cpu-feature-overrides.h> need to be removed, likely
>> > in the same change even, *however* not without double-checking whether
>> > there is not a case among them where a platform actually has LL/SC support
>> > disabled despite the CPU used there having architectural support for the
>> > feature. Otherwise we may end up with a case where a platform has LL/SC
>> > support disabled via its <asm/mach-*/cpu-feature-overrides.h> setting and
>> > yet we enable ARCH_SUPPORTS_ATOMIC_RMW or ARCH_HAVE_NMI_SAFE_CMPXCHG for
>> > it via Kconfig.
>>
>> IMO it's necessary for platforms who know what are they doing such as ATH25,
>> which we took care in this series.
>>
>> I'll add a build time assertion to ensure when CONFIG_CPU_HAS_LLSC is selected
>> kernel_uses_llsc is statically 1, so any incorrect overrides can be spotted
>> at build time.
>
> That might do in the interim as a sanity check, however ultimately the
> sole reason these <asm/mach-*/cpu-feature-overrides.h> exist (and the
> `cpu_has_llsc' setting there) is so that a dynamic check at run time is
> avoided where the result is known from elsewhere beforehand anyway, and
> your change effectively supersedes the overrides, and therefore they need
> to be removed.
>
No, overrides are still valid if platform did CPU_MAY_HAVE_LLSC, this is at
least valid for R10000 systems (IP28 decided to opt-out from llsc somehow),
ATH25 (platform made assumption on IP version shipped with CPU), cavium
octeon (platform decided to opt-out llsc for non-SMP build). I'm not confident
with handling them all in Kconfig so I think the best approach so far is to do
build time assertion.

Does anyone reckon the reason behind opt-out LLSC for IP28? As far as I understand
there is no restriction on using LLSC after workaround being applied. If it's purely
performance reason, I think I'll need to move kernel_uses_llsc logic to Kconfig as well.

Thanks
>
> Maciej

--
- Jiaxun