[PATCH 7/9] riscv: Prepare for unaligned access type table lookups

[Clément Léger]

On 10/02/2025 11:16, Anup Patel wrote:
> On Sat, Feb 8, 2025 at 6:53 AM Charlie Jenkins <charlie at rivosinc.com> wrote:
>>
>> On Fri, Feb 07, 2025 at 05:19:47PM +0100, Andrew Jones wrote:
>>> Probing unaligned accesses on boot is time consuming. Provide a
>>> function which will be used to look up the access type in a table
>>> by id registers. Vendors which provide table entries can then skip
>>> the probing.
>>
>> The access checker in my experience is only time consuming on slow
>> hardware. Hardware that supports fast unaligned accesses isn't really
>> impacted by this? Avoiding a list of hardware that has slow/fast
>> unaligned accesses in the kernel was the main reason for dynamically
>> checking. We did introduce the config option to compile the kernel with
>> assumed slow/fast accesses, which of course has the downside of
>> recompiling the kernel and I assume that you already considered that.
> 
> The kconfig option does not align with the vision of running the same
> kernel image across platforms.

I'd would be advocating to remove compile time options as well and use
another way to skip the probe (see below).

> 
>>
>> Instead of having a table in the kernel, something that would be more
>> platform agnostic would be to have an extension that signals this
>> information. That seems like it would accomplish the same goal and
>> leverage the existing infrastructure in the kernel, albeit with the need
>> to make a new extension.
>>
> 
> IMO, expecting an ISA extension to be defined for all possible
> microarchitectural choices is not going to scale so it is better
> to have infrastructure in kernel itself to infer microarchitectural
> choices based on RISC-V implementation ID.

Since adding an extension seems quite unlikely, and that a device-tree
property is likely DT centric and not applicable to ACPI as well, was a
command line argument considered ?

Thanks,

Clément

> 
> Regards,
> Anup
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv