The 03/11/2022 18:42, Mark Brown wrote: > On Fri, Mar 11, 2022 at 05:21:21PM +0000, Szabolcs Nagy wrote: > > The 02/25/2022 16:58, Mark Brown wrote: > > > +* On creation fork() or clone() the newly created process will have PSTATE.SM > > > + and PSTATE.ZA cleared. > > > is there a reason why fork() clears ZA? > > > i think this is a minor issue, but the usual expectation is that > > on thread creation thread local state is reset in the child, but > > in a forked child the state is the same as in the parent (where > > ZA is preserved according to the first rule). > > It was partly consistency with SM and the SVE state (though that is also > covered by just being in a system call unlike ZA) and partly concerns > about what happens if the fork() happens in library code which isn't SME > aware - it would end up carrying around a copy of ZA with associated > power and performance impacts if it doesn't exec(). Overall it seemed > like there would to be less potential for unpleasant surprises if we > consistently discard the data. > > That's not a *super* strongly held opinion though, we could switch to > preserving whenever we preserve TPIDR2. i think it's slightly better to treat ZA like TPIDR2, so only clear if CLONE_SETTLS is set. otherwise in principle the child can return to the frame where ZA was used and expect it to work (it's hard to come up with a reason why would some code do that, but this is valid in a single-threaded fork child). sorry for not deciding this earlier.
