Andrew Morton reported that AES-NI CTR optimization failed to compile
with gas 2.16.1, the error message is as follow:
arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
To fix this, a gas macro is defined to assemble movq with 64bit
general purpose registers and XMM registers. The macro will generate
the raw .byte sequence for needed instructions.
Reported-by: Andrew Morton <[email protected]>
Signed-off-by: Huang Ying <[email protected]>
---
arch/x86/crypto/aesni-intel_asm.S | 4 -
arch/x86/include/asm/inst.h | 96 ++++++++++++++++++++++++++++++++++++--
2 files changed, 95 insertions(+), 5 deletions(-)
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -749,8 +749,8 @@ _aesni_inc_init:
movaps IV, CTR
PSHUFB_XMM BSWAP_MASK CTR
mov $1, TCTR_LOW
- movq TCTR_LOW, INC
- movq CTR, TCTR_LOW
+ MOVQ_R64_XMM TCTR_LOW INC
+ MOVQ_R64_XMM CTR TCTR_LOW
ret
/*
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -7,7 +7,66 @@
#ifdef __ASSEMBLY__
+#define REG_NUM_INVALID 100
+
+#define REG_TYPE_R64 0
+#define REG_TYPE_XMM 1
+#define REG_TYPE_INVALID 100
+
+ .macro R64_NUM opd r64
+ \opd = REG_NUM_INVALID
+ .ifc \r64,%rax
+ \opd = 0
+ .endif
+ .ifc \r64,%rcx
+ \opd = 1
+ .endif
+ .ifc \r64,%rdx
+ \opd = 2
+ .endif
+ .ifc \r64,%rbx
+ \opd = 3
+ .endif
+ .ifc \r64,%rsp
+ \opd = 4
+ .endif
+ .ifc \r64,%rbp
+ \opd = 5
+ .endif
+ .ifc \r64,%rsi
+ \opd = 6
+ .endif
+ .ifc \r64,%rdi
+ \opd = 7
+ .endif
+ .ifc \r64,%r8
+ \opd = 8
+ .endif
+ .ifc \r64,%r9
+ \opd = 9
+ .endif
+ .ifc \r64,%r10
+ \opd = 10
+ .endif
+ .ifc \r64,%r11
+ \opd = 11
+ .endif
+ .ifc \r64,%r12
+ \opd = 12
+ .endif
+ .ifc \r64,%r13
+ \opd = 13
+ .endif
+ .ifc \r64,%r14
+ \opd = 14
+ .endif
+ .ifc \r64,%r15
+ \opd = 15
+ .endif
+ .endm
+
.macro XMM_NUM opd xmm
+ \opd = REG_NUM_INVALID
.ifc \xmm,%xmm0
\opd = 0
.endif
@@ -58,13 +117,25 @@
.endif
.endm
+ .macro REG_TYPE type reg
+ R64_NUM reg_type_r64 \reg
+ XMM_NUM reg_type_xmm \reg
+ .if reg_type_r64 != REG_NUM_INVALID
+ \type = REG_TYPE_R64
+ .elseif reg_type_xmm != REG_NUM_INVALID
+ \type = REG_TYPE_XMM
+ .else
+ \type = REG_TYPE_INVALID
+ .endif
+ .endm
+
.macro PFX_OPD_SIZE
.byte 0x66
.endm
- .macro PFX_REX opd1 opd2
- .if (\opd1 | \opd2) & 8
- .byte 0x40 | ((\opd1 & 8) >> 3) | ((\opd2 & 8) >> 1)
+ .macro PFX_REX opd1 opd2 W=0
+ .if ((\opd1 | \opd2) & 8) || \W
+ .byte 0x40 | ((\opd1 & 8) >> 3) | ((\opd2 & 8) >> 1) | (\W << 3)
.endif
.endm
@@ -145,6 +216,25 @@
.byte 0x0f, 0x38, 0xdf
MODRM 0xc0 aesdeclast_opd1 aesdeclast_opd2
.endm
+
+ .macro MOVQ_R64_XMM opd1 opd2
+ REG_TYPE movq_r64_xmm_opd1_type \opd1
+ .if movq_r64_xmm_opd1_type == REG_TYPE_XMM
+ XMM_NUM movq_r64_xmm_opd1 \opd1
+ R64_NUM movq_r64_xmm_opd2 \opd2
+ .else
+ R64_NUM movq_r64_xmm_opd1 \opd1
+ XMM_NUM movq_r64_xmm_opd2 \opd2
+ .endif
+ PFX_OPD_SIZE
+ PFX_REX movq_r64_xmm_opd1 movq_r64_xmm_opd2 1
+ .if movq_r64_xmm_opd1_type == REG_TYPE_XMM
+ .byte 0x0f, 0x7e
+ .else
+ .byte 0x0f, 0x6e
+ .endif
+ MODRM 0xc0 movq_r64_xmm_opd1 movq_r64_xmm_opd2
+ .endm
#endif
#endif
On 03/12/2010 09:01 AM, Huang Ying wrote:
> Andrew Morton reported that AES-NI CTR optimization failed to compile
> with gas 2.16.1, the error message is as follow:
>
> arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
> arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
>
> To fix this, a gas macro is defined to assemble movq with 64bit
> general purpose registers and XMM registers. The macro will generate
> the raw .byte sequence for needed instructions.
>
>
Eventually you'll port the entire assembler into macros, as instructions
are introduced more frequently that people upgrade their assemblers.
Maybe we should disable the new features and warn people (and distros)
to upgrade their tools instead.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
From: Avi Kivity <[email protected]>
Date: Fri, 12 Mar 2010 10:37:33 +0200
> Eventually you'll port the entire assembler into macros, as
> instructions are introduced more frequently that people upgrade their
> assemblers. Maybe we should disable the new features and warn people
> (and distros) to upgrade their tools instead.
I totally and completely disagree.
It would have taken more than a year to get Niagara cpu support out to
people if I had done what you are suggesting.
And here we're talking about one instruction in one specialized case
in a very piece of crypto module assembler.
On 03/12/2010 10:42 AM, David Miller wrote:
> From: Avi Kivity<[email protected]>
> Date: Fri, 12 Mar 2010 10:37:33 +0200
>
>
>> Eventually you'll port the entire assembler into macros, as
>> instructions are introduced more frequently that people upgrade their
>> assemblers. Maybe we should disable the new features and warn people
>> (and distros) to upgrade their tools instead.
>>
> I totally and completely disagree.
>
> It would have taken more than a year to get Niagara cpu support out to
> people if I had done what you are suggesting.
>
Strange, that people can install a new kernel, but not a new assembler.
> And here we're talking about one instruction in one specialized case
> in a very piece of crypto module assembler.
>
If it were one place, I'd agree, but there are more. kvm for example
also uses .byte instead of the actual instructions.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
From: Avi Kivity <[email protected]>
Date: Fri, 12 Mar 2010 10:44:58 +0200
> Strange, that people can install a new kernel, but not a new
> assembler.
Someone shouldn't have to upgrade their tools to build the
kernel.
And we work very hard to make sure this is the case except
in the most unavoidable situations.
On 03/12/2010 10:50 AM, David Miller wrote:
> From: Avi Kivity<[email protected]>
> Date: Fri, 12 Mar 2010 10:44:58 +0200
>
>
>> Strange, that people can install a new kernel, but not a new
>> assembler.
>>
> Someone shouldn't have to upgrade their tools to build the
> kernel.
>
The kernel would still build, just without the AES-NI CTR optimization
(or kvm).
> And we work very hard to make sure this is the case except
> in the most unavoidable situations.
>
Why so hard? It has a cost. The user can certainly 'make
AS=~/new-binutils/bin/gas' and it wouldn't even affect the rest of their
system.
tools/as/ anyone?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
On Fri, Mar 12, 2010 at 03:01:47PM +0800, Huang Ying wrote:
> Andrew Morton reported that AES-NI CTR optimization failed to compile
> with gas 2.16.1, the error message is as follow:
>
> arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
> arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
>
> To fix this, a gas macro is defined to assemble movq with 64bit
> general purpose registers and XMM registers. The macro will generate
> the raw .byte sequence for needed instructions.
>
> Reported-by: Andrew Morton <[email protected]>
> Signed-off-by: Huang Ying <[email protected]>
Patch applied. Thanks a lot!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, 12 Mar 2010 15:01:47 +0800
Huang Ying <[email protected]> wrote:
> Andrew Morton reported that AES-NI CTR optimization failed to compile
> with gas 2.16.1, the error message is as follow:
>
> arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
> arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
>
> To fix this, a gas macro is defined to assemble movq with 64bit
> general purpose registers and XMM registers. The macro will generate
> the raw .byte sequence for needed instructions.
>
Still no go.
arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
arch/x86/crypto/aesni-intel_asm.S:752: Error: bad expression
arch/x86/crypto/aesni-intel_asm.S:752: Error: junk at end of line, first unrecognized character is `1'
arch/x86/crypto/aesni-intel_asm.S:753: Error: bad expression
arch/x86/crypto/aesni-intel_asm.S:753: Error: junk at end of line, first unrecognized character is `1'
it doesn't like this:
REG_TYPE movq_r64_xmm_opd1_type \opd1
Hi, Andrew,
On Wed, 2010-03-24 at 05:23 +0800, Andrew Morton wrote:
> On Fri, 12 Mar 2010 15:01:47 +0800
> Huang Ying <[email protected]> wrote:
>
> > Andrew Morton reported that AES-NI CTR optimization failed to compile
> > with gas 2.16.1, the error message is as follow:
> >
> > arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> > arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
> > arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
> >
> > To fix this, a gas macro is defined to assemble movq with 64bit
> > general purpose registers and XMM registers. The macro will generate
> > the raw .byte sequence for needed instructions.
> >
>
> Still no go.
>
> arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> arch/x86/crypto/aesni-intel_asm.S:752: Error: bad expression
> arch/x86/crypto/aesni-intel_asm.S:752: Error: junk at end of line, first unrecognized character is `1'
> arch/x86/crypto/aesni-intel_asm.S:753: Error: bad expression
> arch/x86/crypto/aesni-intel_asm.S:753: Error: junk at end of line, first unrecognized character is `1'
>
> it doesn't like this:
>
> REG_TYPE movq_r64_xmm_opd1_type \opd1
Try to compile the latest kernel with binutils 2.16.1 this time to debug
and verify my fix. Now, with patch followed, aesni-intel_asm.S can be
compiled. But I failed to compile whole kernel with binutils 2.16.1.
First ld report unknown options, after use latest ld instead of that of
2.16.1, "as" reports errors as follow:
AS arch/x86/kernel/acpi/realmode/wakeup.o
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: error: CPU you selected does not support x86-64 instruction set
cc1: warning: -mregparm is ignored in 64-bit mode
Can you tell me how to setup the building environment with binutils
2.16.1? I just build it by hand and make the installed bin directory the
first one in $PATH.
Best Regards,
Huang Ying
------------------------------------------------------------------------>
Subject: [BUGFIX] Fix another AES-NI CTR optimization compiling failure with gas 2.16.1
The previous AES-NI CTR optimization compiling failure gas 2.16.1 fix
introduces another compiling failure by itself. This patch fixes that.
Reported-by: Andrew Morton <[email protected]>
Signed-off-by: Huang Ying <[email protected]>
---
arch/x86/include/asm/inst.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@ -120,9 +120,9 @@
.macro REG_TYPE type reg
R64_NUM reg_type_r64 \reg
XMM_NUM reg_type_xmm \reg
- .if reg_type_r64 != REG_NUM_INVALID
+ .if reg_type_r64 <> REG_NUM_INVALID
\type = REG_TYPE_R64
- .elseif reg_type_xmm != REG_NUM_INVALID
+ .elseif reg_type_xmm <> REG_NUM_INVALID
\type = REG_TYPE_XMM
.else
\type = REG_TYPE_INVALID
On Wed, Mar 24, 2010 at 02:24:18PM +0800, Huang Ying wrote:
>
> Subject: [BUGFIX] Fix another AES-NI CTR optimization compiling failure with gas 2.16.1
>
> The previous AES-NI CTR optimization compiling failure gas 2.16.1 fix
> introduces another compiling failure by itself. This patch fixes that.
>
> Reported-by: Andrew Morton <[email protected]>
> Signed-off-by: Huang Ying <[email protected]>
Patch applied. Thank you.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Wed, 24 Mar 2010 14:24:18 +0800 Huang Ying <[email protected]> wrote:
> Can you tell me how to setup the building environment with binutils
> 2.16.1? I just build it by hand and make the installed bin directory the
> first one in $PATH.
gcc searches an internal search patch before $PATH. They say this can
be overridden with the -B option or the GCC_EXEC_PREFIX environment
var.
For once-off stuff I just get dirty and do `make V=1'. Then copy and
paste the gcc command line and add `-v'. Then copy, paste and edit the
various gcc subcommands.