Re: [PATCH v4 2/2] riscv: accept the atomic extensions this kernel was built with

[Vladimir Kondratiev]

On 11/4/26 23:55, Conor Dooley wrote:
> On Wed, Nov 04, 2026 at 01:23:52PM +0200, Vladimir Kondratiev wrote:
>> On 11/3/26 23:41, Conor Dooley wrote:
>>> That got me thinking though, I feel like this breaks some of the
>>> extension parsing logic in other ways.
>>>
>>> If you putting zalrsc and zaamo in your devicetree, we never do any
>>> backwards processing to set the a extension (we don't do this for any
>>> extensions by design, we only populate "child" extensions based on their
>>> "parent"). If there's some userspace thing that expects to see a in
>>> cpufeature or w/e it'd break. There shouldn't be since a has always been
>>> supported but who knows. You need custom userspace anyway so I honestly
>>> don't give that much of a shit about this going wrong.
>>>
>>> What does "worry" me is hwprobe. Currently you've not modified hwprobe
>>> at all to correctly state that you do not support
>>> RISCV_HWPROBE_BASE_BEHAVIOR_IMA. (and brings up the question of whether
>>> you support RISCV_HWPROBE_BASE_BEHAVIOR_IMA_FD etc!)
>>>
>>> Maybe, again you don't care cos of your custom userspace, but this needs
>>> to be holistic if it is being done at all.
>>> Personally, I don't want to lower the minimum requirements - the people
>>> designing this stuff to run linux should have checked to see what our
>>> requirements were (and have always been...).
>>
>> I will drop this patch and keep advertising "a" because formally it is
>> true - all "a" including amo instructions do work but rather slow. Also,
>> not worth to complicate logic here for (so far) one very special SoC.
> 
> By that logic, do not complicate the kernel at all with this zalrsc-only
> stuff and drop patch 1 too. Please do this properly or do not do it at
> all. If we are introducing the ability to configure the kernel so that
> it runs on systems with only zalrsc, people should be able to run the
> kernel on such systems without a) failing to boot or b) incorrectly
> reporting to userspace what the hardware is capable of doing.

I am reading again risc-v spec, and it says here:
https://docs.riscv.org/reference/isa/v20260120/priv/machine.html

"M-mode can also be used to implement features that are too difficult or
expensive to implement in hardware directly."

I read it like the feature implemented in the M-mode trap considered
"implemented".

Thus in case of AMO emulated in M-mode, it should be considered
"implemented" however slow. Indeed AMO instructions are executed
correctly from the S/U modes standpoint. Program compiled with these
instruction will not crash. It will run quite slow but correctly. So
proper wording would be "slow ZAAMO" and not "unsupported ZAAMO"

Is my interpretation of the spec correct?

Also, you accepted patch set introducing this p8700 SoC with "A" marked
as "implemented", here:
https://lore.kernel.org/all/20261103-agent-lagging-d7fe1c9334f1@spud/

I will follow this direction, keeping "A" as "implemented" and offering
choice to use faster atomics implementation for such system

Thanks, Vladimir