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

[Alan Hayward]

> 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:
> 
>> read looks fine, given this builds on the existing SVE implementation. Although
>> I think effectively managing the different modes in the debugger may be tricky.
> 
> Sadly I don't see any way of handling the hardware in a way that
> doesn't present some kind of hassle.

Agreed - complexity here is from the hardware, so needs handling by the debugger regardless.

> 
>> The .rst files are a huge help too.
> 
> Glad to hear it.
> 
>> What is returned if SME is in streaming mode and I call GETREGSET with NT_ARM_SVE ?
>> What is returned if SME is not in streaming mode and I call GETREGSET with NT_ARM_SSVE ?
> 
> In both cases you'll get the user_sve_header with no register
> payload and neither of the register types flagged.  I'll make
> this a bit more explicit in the documentation, in the SVE
> documentation it currently just talks about no register data
> being available but doesn't ever actually explicitly say why that
> would happen like we do for ZA, it's currently not super helpful.

Ok, that works for me.

> 
>> 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.


> 
>>> +* The presence of SVE is reported to userspace via HWCAP2_SME in the aux vector
>> 
>> SME not SVE?
> 
> Ack, yes.  Well, I guess given that SME should never appear in a
> system without SVE the statement is true but...