On Thu, Feb 10, 2022 at 06:32:46PM +0000, Catalin Marinas wrote: > On Mon, Feb 07, 2022 at 03:20:35PM +0000, Mark Brown wrote: > > +It is implementation defined which if any parts of the SVE state are shared > > +between streaming and non-streaming modes. When switching between modes > > +via software interfaces such as ptrace if no register content is provided as > > +part of switching no state will be assumed to be shared and everything will > > +be zeroed. > Is there anything other than ptrace() here? I read the sigreturn() case > below but did not say anything about changing PSTATE.SM via the > sigcontext. I guess it's similar to ptrace(). The signal handling code requires that register data be provided to restore with either form of SVE data, this falls out of the existing requirement that register data be provided for SVE. > > +4. System call behaviour > > +------------------------- > > +* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the > > + ZA matrix are preserved. > Sorry if this was discussed. What is the rationale for preserving the ZA > registers on syscall? We don't do this for the top part of the Z > registers. In both cases it's mirroring the expected PCS which is that for normal functions they must be called with streaming mode disabled, the high bits of Z may be changed and there is a lazy saving scheme for ZA. The handling of the Z registers falls out of a combination of the fact that the low bits are shared with the V registers and a desire to interoperate with binaries that are only aware of FPSIMD. See: https://github.com/rsandifo-arm/abi-aa/blob/sme-aapcs64/aapcs64/aapcs64.rst for the PCS (it's an open pull request on the AAPCS), if we disable ZA we should really cooperate with the lazy save scheme for ZA in section 6.5 which would involve writing to userspace buffers. Given that we need to support preserving ZA for cases where userspace is preempted it's not really much effort to do that, if userspace doesn't want the cost it can disable ZA before doing a syscall and it means that syscalls don't push userspace code that would otherwise not do anything with ZA to have problems interoperating with the lazy saving scheme. If we don't preserve ZA then userspace will be forced to save it when enabled which increases overall costs, if we do preserve ZA then it's no more expensive for the kernel to save it than userspace, we avoid the cost of restoring in the case where return directly to userspace without context switching and if we do future work to save more lazily then we may be able to avoid some of the saves. > > + as normal. > What does that mean? Is this as per the sve.rst doc (unspecified but > zeroed in practice)? Yes, we will exit streaming mode and proceed as per sve.rst and the rest of the ABI. > > +* Neither the SVE registers nor ZA are used to pass arguments to or receive > > + results from any syscall. > > + > > +* On creation fork() or clone() the newly created process will have PSTATE.SM > > + and PSTATE.ZA cleared. > This looks slightly inconsistent with the first bullet point on ZA being > preserved on syscalls. Why do these differ? Largely just because it's more complicated to implement copying the ZA backing store for this and it seemed more likely that someone would be surprised by a new process getting stuck carrying a potentially large copy of ZA around that it was unaware of than that someone would actually want that to happen. It's not a particularly strongly held opinon. > > +[4] ARM IHI0055C > > + http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf > > + http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html > > + Procedure Call Standard for the ARM 64-bit Architecture (AArch64) > The second link no longer works. I also couldn't find any reference to > [4] but there's a lot of text to scan, so I may have missed it. We don't referenced it, it's just carried over from SVE.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
