* [PATCH v2 0/3] arm64/sve: Fix mutating register endianness on big-endian @ 2019-06-12 16:00 Dave Martin 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Dave Martin @ 2019-06-12 16:00 UTC (permalink / raw) To: linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Julien Grall, Catalin Marinas, Alex Bennée This is a respin of [1], swapping the first two patches so that (new) patch 1 can go to stable stand-alone without depending on patch 2. I've also smuggled in a new trivial patch 3, that just replaces a couple of magic numbers for which there is now a suitable #define to use, which have been bugging me for a while. Original blurb: By inspection while debugging something else, I noticed that the byte order of FPSIMD V-register stores and SVE Z-register stores is not the same when running on big-endian. This is not properly taken into account when moving between the FPSIMD and SVE register views inside the kernel, resulting in the bytes of a V-register getting spontaneously reversed in some situations, from userspace's point of view. The signal frame and ptrace interface are also affected. The KVM ABI forbids mixing the two views and so should not be affected. See patch 2 for details. Patch 1 does some trivial preparatory refactoring. gdb may or may not be affected by this, depending on how it uses the NT_PRFPREG and NT_ARM_SVE regsets. I'll leave it to the developers to assess that. [1] [PATCH 0/2] arm64/sve: Fix mutating register endianness on big-endian http://lists.infradead.org/pipermail/linux-arm-kernel/2019-June/657824.html Dave Martin (3): arm64/sve: Fix missing SVE/FPSIMD endianness conversions arm64/sve: Factor out FPSIMD to SVE state conversion arm64/sve: Fix a couple of magic numbers for the Z-reg count Documentation/arm64/sve.txt | 16 +++++++++++ arch/arm64/include/uapi/asm/kvm.h | 7 +++++ arch/arm64/include/uapi/asm/ptrace.h | 4 +++ arch/arm64/include/uapi/asm/sigcontext.h | 14 +++++++++ arch/arm64/kernel/fpsimd.c | 49 ++++++++++++++++++++++++-------- 5 files changed, 78 insertions(+), 12 deletions(-) -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 16:00 [PATCH v2 0/3] arm64/sve: Fix mutating register endianness on big-endian Dave Martin @ 2019-06-12 16:00 ` Dave Martin 2019-06-12 17:28 ` Will Deacon 2019-06-12 17:46 ` Julien Grall 2019-06-12 16:00 ` [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion Dave Martin 2019-06-12 16:00 ` [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count Dave Martin 2 siblings, 2 replies; 16+ messages in thread From: Dave Martin @ 2019-06-12 16:00 UTC (permalink / raw) To: linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Julien Grall, Catalin Marinas, Alex Bennée 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. Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support") Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- The ptrace change is theoretically an ABI break, but since the current behaviour is obviously wrong, I consider this a fix. Tested on the Arm Fast Model, using: * asm code that mixes SVE instructions and syscalls; * ptrace interactions that mix the SVE_PT_REGS_FPSIMD and SVE_PT_REGS_SVE views of NT_ARM_SVE. Signal frame behaviour not directly tested (since the underlying conversion functions are the same in all cases). Demonstrator code, on a big-endian platform: .arch_extension sve index z0.b, #0, #1 str v0, [x0] // x0 -> 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 mov w8, #__NR_getpid svc #0 // any noop syscall, reverts to non-SVE regs str v0, [x0] // x0 -> 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 mov z0.d, z0.d // triggers an SVE trap and buggy FPSIMD->SVE conversion str v0, [x0] // x0 -> 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f While a "cool feature", this is not what was intended. --- Documentation/arm64/sve.txt | 16 ++++++++++++ arch/arm64/include/uapi/asm/kvm.h | 7 ++++++ arch/arm64/include/uapi/asm/ptrace.h | 4 +++ arch/arm64/include/uapi/asm/sigcontext.h | 14 +++++++++++ arch/arm64/kernel/fpsimd.c | 42 +++++++++++++++++++++++++------- 5 files changed, 74 insertions(+), 9 deletions(-) diff --git a/Documentation/arm64/sve.txt b/Documentation/arm64/sve.txt index 9940e92..6c0bed3 100644 --- a/Documentation/arm64/sve.txt +++ b/Documentation/arm64/sve.txt @@ -56,6 +56,18 @@ model features for SVE is included in Appendix A. is to connect to a target process first and then attempt a ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). +* Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory + between userspace and the kernel, the register value is encoded in memory in + an endianness-invariant layout, with bits [(8 * i + 7) : (8 * i)] encoded at + byte offset i in from the start of the memory representation. This affects + for example the signal frame (struct sve_context) and ptrace interface + (struct user_sve_header) and associated data. + + Beware that on big-endian systems this results in a different byte order than + for the FPSIMD V-registers, which are stored as single host-endian 128-bit + values, with bits [(127 - 8 * i) : (120 - 8 * i)] of the register encoded at + byte offset i. (struct fpsimd_context, struct user_fpsimd_state). + 2. Vector length terminology ----------------------------- @@ -124,6 +136,10 @@ the SVE instruction set architecture. size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to the members. +* Each scalable register (Zn, Pn, FFR) is stored in an endianness-invariant + layout, with bits [(8 * i + 7) : (8 * i)] stored at byte offset i from the + start of the register's representation in memory. + * If the SVE context is too big to fit in sigcontext.__reserved[], then extra space is allocated on the stack, an extra_context record is written in __reserved[] referencing this space. sve_context is then written in the diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 7b7ac0f..072ea1e 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -260,6 +260,13 @@ struct kvm_vcpu_events { KVM_REG_SIZE_U256 | \ ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1))) +/* + * Register values for KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() and + * KVM_REG_ARM64_SVE_FFR() and represented in memory in an endianness- + * invariant layout which differs from the layout used for the FPSIMD + * V-registers on big-endian systems: see sigcontext.h for more explanaion. + */ + #define KVM_ARM64_SVE_VQ_MIN __SVE_VQ_MIN #define KVM_ARM64_SVE_VQ_MAX __SVE_VQ_MAX diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h index d78623a..018bf7d 100644 --- a/arch/arm64/include/uapi/asm/ptrace.h +++ b/arch/arm64/include/uapi/asm/ptrace.h @@ -176,6 +176,10 @@ struct user_sve_header { * FPCR uint32_t FPCR * * Additional data might be appended in the future. + * + * The Z-, P- and FFR registers and represented in memory in an endianness- + * invariant layout which differs from the layout used for the FPSIMD + * V-registers on big-endian systems: see sigcontext.h for more explanaion. */ #define SVE_PT_SVE_ZREG_SIZE(vq) __SVE_ZREG_SIZE(vq) diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h index 5f3c0ce..5231569 100644 --- a/arch/arm64/include/uapi/asm/sigcontext.h +++ b/arch/arm64/include/uapi/asm/sigcontext.h @@ -77,6 +77,15 @@ struct fpsimd_context { __uint128_t vregs[32]; }; +/* + * Note: similarly to all other integer fields, each V-register is stored in an + * endianness-dependent format, with the byte at offset i from the start of the + * in-memory representation of the register value containing + * + * bits [(7 + 8 * i) : (8 * i)] of the register on little-endian hosts; or + * bits [(127 - 8 * i) : (120 - 8 * i)] on big-endian hosts. + */ + /* ESR_EL1 context */ #define ESR_MAGIC 0x45535201 @@ -204,6 +213,11 @@ struct sve_context { * FFR uint16_t[vq] first-fault status register * * Additional data might be appended in the future. + * + * Unlike vregs[] in fpsimd_context, each SVE scalable register (Z-, P- or FFR) + * is encoded in memory an endianness-invariant format, with the byte at offset + * i from the start of the in-memory representation containing bits + * [(7 + 8 * i) : (8 * i)] of the register value. */ #define SVE_SIG_ZREG_SIZE(vq) __SVE_ZREG_SIZE(vq) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index a38bf74..bb42cd0 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -39,6 +39,7 @@ #include <linux/slab.h> #include <linux/stddef.h> #include <linux/sysctl.h> +#include <linux/swab.h> #include <asm/esr.h> #include <asm/fpsimd.h> @@ -352,6 +353,23 @@ static int __init sve_sysctl_init(void) { return 0; } #define ZREG(sve_state, vq, n) ((char *)(sve_state) + \ (SVE_SIG_ZREG_OFFSET(vq, n) - SVE_SIG_REGS_OFFSET)) +#ifdef CONFIG_CPU_BIG_ENDIAN +static __uint128_t arm64_cpu_to_le128(__uint128_t x) +{ + u64 a = swab64(x); + u64 b = swab64(x >> 64); + + return ((__uint128_t)a << 64) | b; +} +#else +static __uint128_t arm64_cpu_to_le128(__uint128_t x) +{ + return x; +} +#endif + +#define arm64_le128_to_cpu(x) arm64_cpu_to_le128(x) + /* * Transfer the FPSIMD state in task->thread.uw.fpsimd_state to * task->thread.sve_state. @@ -369,14 +387,16 @@ static void fpsimd_to_sve(struct task_struct *task) void *sst = task->thread.sve_state; struct user_fpsimd_state const *fst = &task->thread.uw.fpsimd_state; unsigned int i; + __uint128_t *p; if (!system_supports_sve()) return; vq = sve_vq_from_vl(task->thread.sve_vl); - for (i = 0; i < 32; ++i) - memcpy(ZREG(sst, vq, i), &fst->vregs[i], - sizeof(fst->vregs[i])); + for (i = 0; i < 32; ++i) { + p = (__uint128_t *)ZREG(sst, vq, i); + *p = arm64_cpu_to_le128(fst->vregs[i]); + } } /* @@ -395,14 +415,16 @@ static void sve_to_fpsimd(struct task_struct *task) void const *sst = task->thread.sve_state; struct user_fpsimd_state *fst = &task->thread.uw.fpsimd_state; unsigned int i; + __uint128_t const *p; if (!system_supports_sve()) return; vq = sve_vq_from_vl(task->thread.sve_vl); - for (i = 0; i < 32; ++i) - memcpy(&fst->vregs[i], ZREG(sst, vq, i), - sizeof(fst->vregs[i])); + for (i = 0; i < 32; ++i) { + p = (__uint128_t const *)ZREG(sst, vq, i); + fst->vregs[i] = arm64_le128_to_cpu(*p); + } } #ifdef CONFIG_ARM64_SVE @@ -491,6 +513,7 @@ void sve_sync_from_fpsimd_zeropad(struct task_struct *task) void *sst = task->thread.sve_state; struct user_fpsimd_state const *fst = &task->thread.uw.fpsimd_state; unsigned int i; + __uint128_t *p; if (!test_tsk_thread_flag(task, TIF_SVE)) return; @@ -499,9 +522,10 @@ void sve_sync_from_fpsimd_zeropad(struct task_struct *task) memset(sst, 0, SVE_SIG_REGS_SIZE(vq)); - for (i = 0; i < 32; ++i) - memcpy(ZREG(sst, vq, i), &fst->vregs[i], - sizeof(fst->vregs[i])); + for (i = 0; i < 32; ++i) { + p = (__uint128_t *)ZREG(sst, vq, i); + *p = arm64_cpu_to_le128(fst->vregs[i]); + } } int sve_set_vector_length(struct task_struct *task, -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin @ 2019-06-12 17:28 ` Will Deacon 2019-06-27 13:51 ` Catalin Marinas 2019-06-12 17:46 ` Julien Grall 1 sibling, 1 reply; 16+ messages in thread From: Will Deacon @ 2019-06-12 17:28 UTC (permalink / raw) To: Dave Martin Cc: Peter Maydell, gdb, Alan Hayward, Zhang Lei, Julien Grall, Catalin Marinas, Alex Bennée, linux-arm-kernel On Wed, Jun 12, 2019 at 05:00:32PM +0100, 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. > > Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") > Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support") > Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") > Signed-off-by: Dave Martin <Dave.Martin@arm.com> Thanks, Dave. I've picked this one up and pushed it out to our fixes branch for 5.2. I assume Catalin will take the other two for 5.3. It's probably worth proposing some generic 128-bit swab functions too, in case there's any interest (in which case we could drop our local implementation later on). Cheers, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 17:28 ` Will Deacon @ 2019-06-27 13:51 ` Catalin Marinas 2019-06-27 15:18 ` Dave Martin 0 siblings, 1 reply; 16+ messages in thread From: Catalin Marinas @ 2019-06-27 13:51 UTC (permalink / raw) To: Will Deacon Cc: Peter Maydell, gdb, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, Dave Martin, linux-arm-kernel On Wed, Jun 12, 2019 at 06:28:53PM +0100, Will Deacon wrote: > On Wed, Jun 12, 2019 at 05:00:32PM +0100, 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. > > > > Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") > > Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support") > > Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> > > Thanks, Dave. I've picked this one up and pushed it out to our fixes branch > for 5.2. I assume Catalin will take the other two for 5.3. At least the second patch depends on the first one. So I'll postpone merging them until -rc1. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-27 13:51 ` Catalin Marinas @ 2019-06-27 15:18 ` Dave Martin 0 siblings, 0 replies; 16+ messages in thread From: Dave Martin @ 2019-06-27 15:18 UTC (permalink / raw) To: Catalin Marinas Cc: Peter Maydell, gdb, Will Deacon, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, linux-arm-kernel On Thu, Jun 27, 2019 at 02:51:13PM +0100, Catalin Marinas wrote: > On Wed, Jun 12, 2019 at 06:28:53PM +0100, Will Deacon wrote: > > On Wed, Jun 12, 2019 at 05:00:32PM +0100, 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. > > > > > > Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") > > > Fixes: 8cd969d28fd2 ("arm64/sve: Signal handling support") > > > Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support") > > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> > > > > Thanks, Dave. I've picked this one up and pushed it out to our fixes branch > > for 5.2. I assume Catalin will take the other two for 5.3. > > At least the second patch depends on the first one. So I'll postpone > merging them until -rc1. Yes, that should be fine. Those are cleanup, supplementary to the fix. Thanks ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin 2019-06-12 17:28 ` Will Deacon @ 2019-06-12 17:46 ` Julien Grall 2019-06-13 9:22 ` Will Deacon 2019-06-13 10:00 ` Dave Martin 1 sibling, 2 replies; 16+ messages in thread From: Julien Grall @ 2019-06-12 17:46 UTC (permalink / raw) To: Dave Martin, linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Catalin Marinas, Alex Bennée Hi Dave, 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. [...] > diff --git a/Documentation/arm64/sve.txt b/Documentation/arm64/sve.txt > index 9940e92..6c0bed3 100644 > --- a/Documentation/arm64/sve.txt > +++ b/Documentation/arm64/sve.txt > @@ -56,6 +56,18 @@ model features for SVE is included in Appendix A. > is to connect to a target process first and then attempt a > ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). > > +* Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory > + between userspace and the kernel, the register value is encoded in memory in > + an endianness-invariant layout, with bits [(8 * i + 7) : (8 * i)] encoded at > + byte offset i in from the start of the memory representation. This affects > + for example the signal frame (struct sve_context) and ptrace interface > + (struct user_sve_header) and associated data. > + > + Beware that on big-endian systems this results in a different byte order than > + for the FPSIMD V-registers, which are stored as single host-endian 128-bit > + values, with bits [(127 - 8 * i) : (120 - 8 * i)] of the register encoded at > + byte offset i. (struct fpsimd_context, struct user_fpsimd_state). > + > > 2. Vector length terminology > ----------------------------- > @@ -124,6 +136,10 @@ the SVE instruction set architecture. > size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to > the members. > > +* Each scalable register (Zn, Pn, FFR) is stored in an endianness-invariant > + layout, with bits [(8 * i + 7) : (8 * i)] stored at byte offset i from the > + start of the register's representation in memory. > + > * If the SVE context is too big to fit in sigcontext.__reserved[], then extra > space is allocated on the stack, an extra_context record is written in > __reserved[] referencing this space. sve_context is then written in the > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 7b7ac0f..072ea1e 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -260,6 +260,13 @@ struct kvm_vcpu_events { > KVM_REG_SIZE_U256 | \ > ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1))) > > +/* > + * Register values for KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() and > + * KVM_REG_ARM64_SVE_FFR() and represented in memory in an endianness- NIT: s/and represented/are represented/ I think. > + * invariant layout which differs from the layout used for the FPSIMD > + * V-registers on big-endian systems: see sigcontext.h for more explanaion. NIT: s/explanaion/explanation/ Cheers, -- Julien Grall _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 17:46 ` Julien Grall @ 2019-06-13 9:22 ` Will Deacon 2019-06-13 10:00 ` Dave Martin 1 sibling, 0 replies; 16+ messages in thread From: Will Deacon @ 2019-06-13 9:22 UTC (permalink / raw) To: Julien Grall Cc: Peter Maydell, gdb, Alan Hayward, Zhang Lei, Catalin Marinas, Alex Bennée, Dave Martin, linux-arm-kernel 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-12 17:46 ` Julien Grall 2019-06-13 9:22 ` Will Deacon @ 2019-06-13 10:00 ` Dave Martin 2019-06-13 10:17 ` Will Deacon 1 sibling, 1 reply; 16+ messages in thread From: Dave Martin @ 2019-06-13 10:00 UTC (permalink / raw) To: Julien Grall Cc: Peter Maydell, Catalin Marinas, gdb, Will Deacon, Zhang Lei, Alan Hayward, Alex Bennée, linux-arm-kernel On Wed, Jun 12, 2019 at 06:46:04PM +0100, Julien Grall wrote: > Hi Dave, > > 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. > > [...] > > >diff --git a/Documentation/arm64/sve.txt b/Documentation/arm64/sve.txt > >index 9940e92..6c0bed3 100644 > >--- a/Documentation/arm64/sve.txt > >+++ b/Documentation/arm64/sve.txt > >@@ -56,6 +56,18 @@ model features for SVE is included in Appendix A. > > is to connect to a target process first and then attempt a > > ptrace(PTRACE_GETREGSET, pid, NT_ARM_SVE, &iov). > >+* Whenever SVE scalable register values (Zn, Pn, FFR) are exchanged in memory > >+ between userspace and the kernel, the register value is encoded in memory in > >+ an endianness-invariant layout, with bits [(8 * i + 7) : (8 * i)] encoded at > >+ byte offset i in from the start of the memory representation. This affects > >+ for example the signal frame (struct sve_context) and ptrace interface > >+ (struct user_sve_header) and associated data. > >+ > >+ Beware that on big-endian systems this results in a different byte order than > >+ for the FPSIMD V-registers, which are stored as single host-endian 128-bit > >+ values, with bits [(127 - 8 * i) : (120 - 8 * i)] of the register encoded at > >+ byte offset i. (struct fpsimd_context, struct user_fpsimd_state). > >+ > > 2. Vector length terminology > > ----------------------------- > >@@ -124,6 +136,10 @@ the SVE instruction set architecture. > > size and layout. Macros SVE_SIG_* are defined [1] to facilitate access to > > the members. > >+* Each scalable register (Zn, Pn, FFR) is stored in an endianness-invariant > >+ layout, with bits [(8 * i + 7) : (8 * i)] stored at byte offset i from the > >+ start of the register's representation in memory. > >+ > > * If the SVE context is too big to fit in sigcontext.__reserved[], then extra > > space is allocated on the stack, an extra_context record is written in > > __reserved[] referencing this space. sve_context is then written in the > >diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > >index 7b7ac0f..072ea1e 100644 > >--- a/arch/arm64/include/uapi/asm/kvm.h > >+++ b/arch/arm64/include/uapi/asm/kvm.h > >@@ -260,6 +260,13 @@ struct kvm_vcpu_events { > > KVM_REG_SIZE_U256 | \ > > ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1))) > >+/* > >+ * Register values for KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() and > >+ * KVM_REG_ARM64_SVE_FFR() and represented in memory in an endianness- > > NIT: s/and represented/are represented/ I think. > > >+ * invariant layout which differs from the layout used for the FPSIMD > >+ * V-registers on big-endian systems: see sigcontext.h for more explanaion. > > NIT: s/explanaion/explanation/ Dang, the first of these two is quite confusing. I might send a fix for that, but I guess it's not urgent. Thanks for spotting it. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-13 10:00 ` Dave Martin @ 2019-06-13 10:17 ` Will Deacon 2019-06-13 10:20 ` Dave Martin 0 siblings, 1 reply; 16+ messages in thread From: Will Deacon @ 2019-06-13 10:17 UTC (permalink / raw) To: Dave Martin Cc: Peter Maydell, Catalin Marinas, gdb, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, linux-arm-kernel On Thu, Jun 13, 2019 at 11:00:34AM +0100, Dave Martin wrote: > On Wed, Jun 12, 2019 at 06:46:04PM +0100, Julien Grall wrote: > > On 12/06/2019 17:00, Dave Martin wrote: > > >diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > > >index 7b7ac0f..072ea1e 100644 > > >--- a/arch/arm64/include/uapi/asm/kvm.h > > >+++ b/arch/arm64/include/uapi/asm/kvm.h > > >@@ -260,6 +260,13 @@ struct kvm_vcpu_events { > > > KVM_REG_SIZE_U256 | \ > > > ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1))) > > >+/* > > >+ * Register values for KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() and > > >+ * KVM_REG_ARM64_SVE_FFR() and represented in memory in an endianness- > > > > NIT: s/and represented/are represented/ I think. > > > > >+ * invariant layout which differs from the layout used for the FPSIMD > > >+ * V-registers on big-endian systems: see sigcontext.h for more explanaion. > > > > NIT: s/explanaion/explanation/ > > Dang, the first of these two is quite confusing. > > I might send a fix for that, but I guess it's not urgent. Thanks for > spotting it. I've pushed an updated version out so hopefully no need to do anything more. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions 2019-06-13 10:17 ` Will Deacon @ 2019-06-13 10:20 ` Dave Martin 0 siblings, 0 replies; 16+ messages in thread From: Dave Martin @ 2019-06-13 10:20 UTC (permalink / raw) To: Will Deacon Cc: Peter Maydell, Catalin Marinas, gdb, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, linux-arm-kernel On Thu, Jun 13, 2019 at 11:17:27AM +0100, Will Deacon wrote: > On Thu, Jun 13, 2019 at 11:00:34AM +0100, Dave Martin wrote: > > On Wed, Jun 12, 2019 at 06:46:04PM +0100, Julien Grall wrote: > > > On 12/06/2019 17:00, Dave Martin wrote: > > > >diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > > > >index 7b7ac0f..072ea1e 100644 > > > >--- a/arch/arm64/include/uapi/asm/kvm.h > > > >+++ b/arch/arm64/include/uapi/asm/kvm.h > > > >@@ -260,6 +260,13 @@ struct kvm_vcpu_events { > > > > KVM_REG_SIZE_U256 | \ > > > > ((i) & (KVM_ARM64_SVE_MAX_SLICES - 1))) > > > >+/* > > > >+ * Register values for KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() and > > > >+ * KVM_REG_ARM64_SVE_FFR() and represented in memory in an endianness- > > > > > > NIT: s/and represented/are represented/ I think. > > > > > > >+ * invariant layout which differs from the layout used for the FPSIMD > > > >+ * V-registers on big-endian systems: see sigcontext.h for more explanaion. > > > > > > NIT: s/explanaion/explanation/ > > > > Dang, the first of these two is quite confusing. > > > > I might send a fix for that, but I guess it's not urgent. Thanks for > > spotting it. > > I've pushed an updated version out so hopefully no need to do anything more. Ah, OK. Great. Thanks ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion 2019-06-12 16:00 [PATCH v2 0/3] arm64/sve: Fix mutating register endianness on big-endian Dave Martin 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin @ 2019-06-12 16:00 ` Dave Martin 2019-06-20 13:45 ` Julien Grall 2019-07-22 10:31 ` Catalin Marinas 2019-06-12 16:00 ` [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count Dave Martin 2 siblings, 2 replies; 16+ messages in thread From: Dave Martin @ 2019-06-12 16:00 UTC (permalink / raw) To: linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Julien Grall, Catalin Marinas, Alex Bennée Currently we convert from FPSIMD to SVE register state in memory in two places. To ease future maintenance, let's consolidate this in one place. Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/kernel/fpsimd.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index bb42cd0..d2f7544 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -370,6 +370,18 @@ static __uint128_t arm64_cpu_to_le128(__uint128_t x) #define arm64_le128_to_cpu(x) arm64_cpu_to_le128(x) +static void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst, + unsigned int vq) +{ + unsigned int i; + __uint128_t *p; + + for (i = 0; i < 32; ++i) { + p = (__uint128_t *)ZREG(sst, vq, i); + *p = arm64_cpu_to_le128(fst->vregs[i]); + } +} + /* * Transfer the FPSIMD state in task->thread.uw.fpsimd_state to * task->thread.sve_state. @@ -386,17 +398,12 @@ static void fpsimd_to_sve(struct task_struct *task) unsigned int vq; void *sst = task->thread.sve_state; struct user_fpsimd_state const *fst = &task->thread.uw.fpsimd_state; - unsigned int i; - __uint128_t *p; if (!system_supports_sve()) return; vq = sve_vq_from_vl(task->thread.sve_vl); - for (i = 0; i < 32; ++i) { - p = (__uint128_t *)ZREG(sst, vq, i); - *p = arm64_cpu_to_le128(fst->vregs[i]); - } + __fpsimd_to_sve(sst, fst, vq); } /* @@ -512,8 +519,6 @@ void sve_sync_from_fpsimd_zeropad(struct task_struct *task) unsigned int vq; void *sst = task->thread.sve_state; struct user_fpsimd_state const *fst = &task->thread.uw.fpsimd_state; - unsigned int i; - __uint128_t *p; if (!test_tsk_thread_flag(task, TIF_SVE)) return; @@ -521,11 +526,7 @@ void sve_sync_from_fpsimd_zeropad(struct task_struct *task) vq = sve_vq_from_vl(task->thread.sve_vl); memset(sst, 0, SVE_SIG_REGS_SIZE(vq)); - - for (i = 0; i < 32; ++i) { - p = (__uint128_t *)ZREG(sst, vq, i); - *p = arm64_cpu_to_le128(fst->vregs[i]); - } + __fpsimd_to_sve(sst, fst, vq); } int sve_set_vector_length(struct task_struct *task, -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion 2019-06-12 16:00 ` [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion Dave Martin @ 2019-06-20 13:45 ` Julien Grall 2019-07-22 10:31 ` Catalin Marinas 1 sibling, 0 replies; 16+ messages in thread From: Julien Grall @ 2019-06-20 13:45 UTC (permalink / raw) To: Dave Martin, linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Catalin Marinas, Alex Bennée Hi Dave, On 6/12/19 5:00 PM, Dave Martin wrote: > Currently we convert from FPSIMD to SVE register state in memory in > two places. > > To ease future maintenance, let's consolidate this in one place. > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Cheers, -- Julien Grall _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion 2019-06-12 16:00 ` [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion Dave Martin 2019-06-20 13:45 ` Julien Grall @ 2019-07-22 10:31 ` Catalin Marinas 1 sibling, 0 replies; 16+ messages in thread From: Catalin Marinas @ 2019-07-22 10:31 UTC (permalink / raw) To: Dave Martin Cc: Peter Maydell, gdb, Will Deacon, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, linux-arm-kernel On Wed, Jun 12, 2019 at 05:00:33PM +0100, Dave P Martin wrote: > Currently we convert from FPSIMD to SVE register state in memory in > two places. > > To ease future maintenance, let's consolidate this in one place. > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> Now that we are at 5.3-rc1 and Will is queuing fixes, he can take this patch as well (I didn't queue it for the merging window because of a dependency on the first patch). Acked-by: Catalin Marinas <catalin.marinas@arm.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count 2019-06-12 16:00 [PATCH v2 0/3] arm64/sve: Fix mutating register endianness on big-endian Dave Martin 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin 2019-06-12 16:00 ` [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion Dave Martin @ 2019-06-12 16:00 ` Dave Martin 2019-06-20 13:43 ` Julien Grall 2019-07-22 10:32 ` Catalin Marinas 2 siblings, 2 replies; 16+ messages in thread From: Dave Martin @ 2019-06-12 16:00 UTC (permalink / raw) To: linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Julien Grall, Catalin Marinas, Alex Bennée There are some hand-written instances of "32" to express the number of SVE Z-registers. Since this code was written a #define was added for this, so convert trivial instances of this magic number as appropriate. No functional change. Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- arch/arm64/kernel/fpsimd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index d2f7544..a5702c3 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -376,7 +376,7 @@ static void __fpsimd_to_sve(void *sst, struct user_fpsimd_state const *fst, unsigned int i; __uint128_t *p; - for (i = 0; i < 32; ++i) { + for (i = 0; i < SVE_NUM_ZREGS; ++i) { p = (__uint128_t *)ZREG(sst, vq, i); *p = arm64_cpu_to_le128(fst->vregs[i]); } @@ -428,7 +428,7 @@ static void sve_to_fpsimd(struct task_struct *task) return; vq = sve_vq_from_vl(task->thread.sve_vl); - for (i = 0; i < 32; ++i) { + for (i = 0; i < SVE_NUM_ZREGS; ++i) { p = (__uint128_t const *)ZREG(sst, vq, i); fst->vregs[i] = arm64_le128_to_cpu(*p); } -- 2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count 2019-06-12 16:00 ` [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count Dave Martin @ 2019-06-20 13:43 ` Julien Grall 2019-07-22 10:32 ` Catalin Marinas 1 sibling, 0 replies; 16+ messages in thread From: Julien Grall @ 2019-06-20 13:43 UTC (permalink / raw) To: Dave Martin, linux-arm-kernel Cc: Peter Maydell, gdb, Alan Hayward, Will Deacon, Zhang Lei, Catalin Marinas, Alex Bennée Hi Dave, On 6/12/19 5:00 PM, Dave Martin wrote: > There are some hand-written instances of "32" to express the number > of SVE Z-registers. > > Since this code was written a #define was added for this, so > convert trivial instances of this magic number as appropriate. > > No functional change. > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Cheers, -- Julien Grall _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count 2019-06-12 16:00 ` [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count Dave Martin 2019-06-20 13:43 ` Julien Grall @ 2019-07-22 10:32 ` Catalin Marinas 1 sibling, 0 replies; 16+ messages in thread From: Catalin Marinas @ 2019-07-22 10:32 UTC (permalink / raw) To: Dave Martin Cc: Peter Maydell, gdb, Will Deacon, Zhang Lei, Julien Grall, Alan Hayward, Alex Bennée, linux-arm-kernel On Wed, Jun 12, 2019 at 05:00:34PM +0100, Dave P Martin wrote: > There are some hand-written instances of "32" to express the number > of SVE Z-registers. > > Since this code was written a #define was added for this, so > convert trivial instances of this magic number as appropriate. > > No functional change. > > Signed-off-by: Dave Martin <Dave.Martin@arm.com> Same here, Will can queue this for -rc2. Acked-by: Catalin Marinas <catalin.marinas@arm.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-07-22 10:32 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-12 16:00 [PATCH v2 0/3] arm64/sve: Fix mutating register endianness on big-endian Dave Martin 2019-06-12 16:00 ` [PATCH v2 1/3] arm64/sve: Fix missing SVE/FPSIMD endianness conversions Dave Martin 2019-06-12 17:28 ` Will Deacon 2019-06-27 13:51 ` Catalin Marinas 2019-06-27 15:18 ` Dave Martin 2019-06-12 17:46 ` Julien Grall 2019-06-13 9:22 ` Will Deacon 2019-06-13 10:00 ` Dave Martin 2019-06-13 10:17 ` Will Deacon 2019-06-13 10:20 ` Dave Martin 2019-06-12 16:00 ` [PATCH v2 2/3] arm64/sve: Factor out FPSIMD to SVE state conversion Dave Martin 2019-06-20 13:45 ` Julien Grall 2019-07-22 10:31 ` Catalin Marinas 2019-06-12 16:00 ` [PATCH v2 3/3] arm64/sve: Fix a couple of magic numbers for the Z-reg count Dave Martin 2019-06-20 13:43 ` Julien Grall 2019-07-22 10:32 ` Catalin Marinas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).