Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions

Will Deacon <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.linux.ports.arm.kernel
Message-ID <[email protected]>
On Wed, Jun 12, 2019 at 06:46:04PM +0100, Julien Grall wrote:
> On 12/06/2019 17:00, Dave Martin wrote:
> > The in-memory representation of SVE and FPSIMD registers is
> > different: the FPSIMD V-registers are stored as single 128-bit
> > host-endian values, whereas SVE registers are stored in an
> > endianness-invariant byte order.
> > 
> > This means that the two representations differ when running on a
> > big-endian host.  But we blindly copy data from one representation
> > to another when converting between the two, resulting in the
> > register contents being unintentionally byteswapped in certain
> > situations.  Currently this can be triggered by the first SVE
> > instruction after a syscall, for example (though the potential
> > trigger points may vary in future).
> > 
> > So, fix the conversion functions fpsimd_to_sve(), sve_to_fpsimd()
> > and sve_sync_from_fpsimd_zeropad() to swab where appropriate.
> > 
> > There is no common swahl128() or swab128() that we could use here.
> > Maybe it would be worth making this generic, but for now add a
> > simple local hack.
> > 
> > Since the byte order differences are exposed in ABI, also clarify
> > the docuentation.
> 
> NIT: s/docuentation/documentation/
> 
> Although, it is probably too late to fix this one as Will already took the patch.

I actually spotted (and fixed) that one when I committed the patch, but I
missed the others. Given that this is top of the fixes branch, I can
probably just fold these in.

Will
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.