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. > 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. > 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. > > +* 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...
Attachment:
signature.asc
Description: PGP signature
