On Wed, Jul 20, 2022 at 10:20:23AM +0100, Will Deacon wrote: > On Tue, Jul 19, 2022 at 08:35:46PM +0100, Mark Brown wrote: > > On Tue, Jul 19, 2022 at 06:35:37PM +0100, Catalin Marinas wrote: > > > > The sysctl is disabled by default since it is anticipated that the risk > > > > of disruption to userspace is low. As well as being within the > > > > documented ABI this new behaviour mirrors the standard function call ABI > > > > for SVE in the AAPCS which should mean that compiler generated code is > > > > unlikely to rely on the current behaviour, the main risk is from hand > > > > coded assembly which directly invokes syscalls. The new behaviour is > > > > also what is currently implemented by qemu user mode emulation. > > > IIRC both Will and Mark R commented in the past that they'd like the > > > current de-facto ABI to become the official one. I'll let them comment. > > That would be good. I've not heard anything from Will either directly > > or indirectly. Mark R has indicated privately directly to me that he > > originally pushed for the currently implemented behaviour and prefers > > it. Marc Zyngier has previously noted publicly the current behaviour > > being a consideration in the context of discusion of optimisation ideas > > like this one, I was a bit surprised that he commented on an earlier > > patch in the series but not this one. You have previously pushed back > > on an attempt to document the current ABI, that was the main motivation > > for writing this patch. > I remember discussing this somewhere at some point with somebody, but that's > not a tonne of use! > My opinion is that the observable behaviour is what matters. So if we > documented that the register state is "undefined" but it is in fact always > zero, then we should fix the documentation. It's always zero with Linux, never zeroed by qemu user. > Does that help? Yes, that's clear thanks though it does differ from what Catalin has said about keeping the flexibility in the documentation - Catalin?
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
