[PATCH v1 12/38] arm64/sme: Provide ABI documentation for SME

[Alan Hayward]

> On 8 Oct 2021, at 18:04, Mark Brown <broonie at kernel.org> wrote:
> 
> On Fri, Oct 08, 2021 at 04:45:44PM +0000, Alan Hayward wrote:
>>> On 8 Oct 2021, at 16:28, Mark Brown <broonie at kernel.org> wrote:
>>> On Fri, Oct 08, 2021 at 02:11:46PM +0000, Alan Hayward wrote:
> 
>>>> Can NT_ARM_SSVE return a fpsimd?
> 
>>> It's documented that way for simplicity but in the current
>>> implementation it won't ever actually do so in practice.  The
>>> only case where I could see that it might happen would be if we
>>> change the syscalls to stay in streaming mode over syscall, in
>>> that case we could do as we do for SVE and preserve FPSIMD
>>> registers only.  At present we drop out of streaming mode if we
>>> get a syscall with it enabled so it's a non-issue, if people
>>> agree that that's the right thing for the syscalls then we should
>>> update the documentation to specify this since otherwise we'll
>>> doubtless catch someone by surprise if we ever manage to start
>>> doing it in the future.
> 
>> ….or it’ll end up executing some code that was written to cope with fpsimd, but has never been
>> run. Might be worth making it explicit in the documentation.
> 
> I will if/when it gets fixed that way.  Actually, while looking
> at that code I was tempted to remove the support for returning
> FPSIMD only registers via NT_ARM_SVE entirely and just always
> convert to SVE format - I'm not sure what the use case was there?
> It's not a pressing thing but it seemed like it was a bit of an
> implementation detail that we were revealing.


What about in the write registers case?

With the existing code:
Read SVE registers with ptrace. Get FPSIMD. Update FPSIMD with new values. Write back to ptrace.
In that scenario, the internal SVE states stays “inactive” in the kernel.

If ptrace always returned an SVE structure, then writing back with the same structure would cause the
SVE state to become active. It’s a small difference, but we really don’t want the debugger to effect things.

You could solve that by adding an SVE_STATE_INACTIVE to the header flags. But, either way, the
debugger would then need to support the existing method and the new method (because the debugger
has no control on what OS version it’s running on).

I’d recommend leaving as is.


Alan.