2019-06-03 08:44:46 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2005-06-26 01:57:56 +04:00
|
|
|
/*
|
|
|
|
* relocate_kernel.S - put the kernel image in place to boot
|
|
|
|
* Copyright (C) 2002-2004 Eric Biederman <ebiederm@xmission.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/linkage.h>
|
2009-02-13 22:14:01 +03:00
|
|
|
#include <asm/page_types.h>
|
2006-09-26 12:52:38 +04:00
|
|
|
#include <asm/kexec.h>
|
2008-03-23 00:00:08 +03:00
|
|
|
#include <asm/processor-flags.h>
|
2006-09-26 12:52:38 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Must be relocatable PIC code callable as a C function
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define PTR(x) (x << 2)
|
|
|
|
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* control_page + KEXEC_CONTROL_CODE_MAX_SIZE
|
2008-08-15 11:40:23 +04:00
|
|
|
* ~ control_page + PAGE_SIZE are used as data storage and stack for
|
|
|
|
* jumping back
|
2008-07-26 06:45:07 +04:00
|
|
|
*/
|
2008-08-15 11:40:23 +04:00
|
|
|
#define DATA(offset) (KEXEC_CONTROL_CODE_MAX_SIZE+(offset))
|
2008-07-26 06:45:07 +04:00
|
|
|
|
|
|
|
/* Minimal CPU state */
|
|
|
|
#define ESP DATA(0x0)
|
|
|
|
#define CR0 DATA(0x4)
|
|
|
|
#define CR3 DATA(0x8)
|
|
|
|
#define CR4 DATA(0xc)
|
|
|
|
|
|
|
|
/* other data */
|
|
|
|
#define CP_VA_CONTROL_PAGE DATA(0x10)
|
|
|
|
#define CP_PA_PGD DATA(0x14)
|
|
|
|
#define CP_PA_SWAP_PAGE DATA(0x18)
|
|
|
|
#define CP_PA_BACKUP_PAGES_MAP DATA(0x1c)
|
|
|
|
|
2006-09-26 12:52:38 +04:00
|
|
|
.text
|
|
|
|
.globl relocate_kernel
|
|
|
|
relocate_kernel:
|
2008-07-26 06:45:07 +04:00
|
|
|
/* Save the CPU context, used for jumping back */
|
|
|
|
|
|
|
|
pushl %ebx
|
|
|
|
pushl %esi
|
|
|
|
pushl %edi
|
|
|
|
pushl %ebp
|
|
|
|
pushf
|
|
|
|
|
|
|
|
movl 20+8(%esp), %ebp /* list of pages */
|
|
|
|
movl PTR(VA_CONTROL_PAGE)(%ebp), %edi
|
|
|
|
movl %esp, ESP(%edi)
|
|
|
|
movl %cr0, %eax
|
|
|
|
movl %eax, CR0(%edi)
|
|
|
|
movl %cr3, %eax
|
|
|
|
movl %eax, CR3(%edi)
|
|
|
|
movl %cr4, %eax
|
|
|
|
movl %eax, CR4(%edi)
|
2006-09-26 12:52:38 +04:00
|
|
|
|
2005-06-26 01:57:56 +04:00
|
|
|
/* read the arguments and say goodbye to the stack */
|
2008-07-26 06:45:07 +04:00
|
|
|
movl 20+4(%esp), %ebx /* page_list */
|
|
|
|
movl 20+8(%esp), %ebp /* list of pages */
|
|
|
|
movl 20+12(%esp), %edx /* start address */
|
|
|
|
movl 20+16(%esp), %ecx /* cpu_has_pae */
|
|
|
|
movl 20+20(%esp), %esi /* preserve_context */
|
2005-06-26 01:57:56 +04:00
|
|
|
|
|
|
|
/* zero out flags, and disable interrupts */
|
|
|
|
pushl $0
|
|
|
|
popfl
|
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
/* save some information for jumping back */
|
|
|
|
movl PTR(VA_CONTROL_PAGE)(%ebp), %edi
|
|
|
|
movl %edi, CP_VA_CONTROL_PAGE(%edi)
|
|
|
|
movl PTR(PA_PGD)(%ebp), %eax
|
|
|
|
movl %eax, CP_PA_PGD(%edi)
|
|
|
|
movl PTR(PA_SWAP_PAGE)(%ebp), %eax
|
|
|
|
movl %eax, CP_PA_SWAP_PAGE(%edi)
|
|
|
|
movl %ebx, CP_PA_BACKUP_PAGES_MAP(%edi)
|
|
|
|
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* get physical address of control page now
|
|
|
|
* this is impossible after page table switch
|
|
|
|
*/
|
2006-09-26 12:52:38 +04:00
|
|
|
movl PTR(PA_CONTROL_PAGE)(%ebp), %edi
|
2005-06-26 01:57:56 +04:00
|
|
|
|
2006-09-26 12:52:38 +04:00
|
|
|
/* switch to new set of page tables */
|
|
|
|
movl PTR(PA_PGD)(%ebp), %eax
|
|
|
|
movl %eax, %cr3
|
|
|
|
|
|
|
|
/* setup a new stack at the end of the physical control page */
|
2008-03-23 00:00:07 +03:00
|
|
|
lea PAGE_SIZE(%edi), %esp
|
2006-09-26 12:52:38 +04:00
|
|
|
|
|
|
|
/* jump to identity mapped page */
|
|
|
|
movl %edi, %eax
|
|
|
|
addl $(identity_mapped - relocate_kernel), %eax
|
|
|
|
pushl %eax
|
|
|
|
ret
|
|
|
|
|
|
|
|
identity_mapped:
|
2011-07-14 05:34:37 +04:00
|
|
|
/* set return address to 0 if not preserving context */
|
|
|
|
pushl $0
|
2006-09-26 12:52:38 +04:00
|
|
|
/* store the start address on the stack */
|
|
|
|
pushl %edx
|
2005-06-26 01:57:56 +04:00
|
|
|
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* Set cr0 to a known state:
|
2008-03-23 00:00:08 +03:00
|
|
|
* - Paging disabled
|
|
|
|
* - Alignment check disabled
|
|
|
|
* - Write protect disabled
|
|
|
|
* - No task switch
|
|
|
|
* - Don't do FP software emulation.
|
|
|
|
* - Proctected mode enabled
|
2005-06-26 01:57:56 +04:00
|
|
|
*/
|
|
|
|
movl %cr0, %eax
|
2008-03-23 00:00:08 +03:00
|
|
|
andl $~(X86_CR0_PG | X86_CR0_AM | X86_CR0_WP | X86_CR0_TS | X86_CR0_EM), %eax
|
|
|
|
orl $(X86_CR0_PE), %eax
|
2005-06-26 01:57:56 +04:00
|
|
|
movl %eax, %cr0
|
|
|
|
|
|
|
|
/* clear cr4 if applicable */
|
|
|
|
testl %ecx, %ecx
|
|
|
|
jz 1f
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* Set cr4 to a known state:
|
2005-06-26 01:57:56 +04:00
|
|
|
* Setting everything to zero seems safe.
|
|
|
|
*/
|
2008-03-23 00:00:06 +03:00
|
|
|
xorl %eax, %eax
|
2005-06-26 01:57:56 +04:00
|
|
|
movl %eax, %cr4
|
|
|
|
|
|
|
|
jmp 1f
|
|
|
|
1:
|
|
|
|
|
|
|
|
/* Flush the TLB (needed?) */
|
|
|
|
xorl %eax, %eax
|
|
|
|
movl %eax, %cr3
|
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
movl CP_PA_SWAP_PAGE(%edi), %eax
|
|
|
|
pushl %eax
|
|
|
|
pushl %ebx
|
|
|
|
call swap_pages
|
|
|
|
addl $8, %esp
|
|
|
|
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* To be certain of avoiding problems with self-modifying code
|
2008-07-26 06:45:07 +04:00
|
|
|
* I need to execute a serializing instruction here.
|
|
|
|
* So I flush the TLB, it's handy, and not processor dependent.
|
|
|
|
*/
|
|
|
|
xorl %eax, %eax
|
|
|
|
movl %eax, %cr3
|
|
|
|
|
2009-03-10 05:56:57 +03:00
|
|
|
/*
|
|
|
|
* set all of the registers to known values
|
|
|
|
* leave %esp alone
|
|
|
|
*/
|
2008-07-26 06:45:07 +04:00
|
|
|
|
|
|
|
testl %esi, %esi
|
|
|
|
jnz 1f
|
|
|
|
xorl %edi, %edi
|
|
|
|
xorl %eax, %eax
|
|
|
|
xorl %ebx, %ebx
|
|
|
|
xorl %ecx, %ecx
|
|
|
|
xorl %edx, %edx
|
|
|
|
xorl %esi, %esi
|
|
|
|
xorl %ebp, %ebp
|
|
|
|
ret
|
|
|
|
1:
|
|
|
|
popl %edx
|
|
|
|
movl CP_PA_SWAP_PAGE(%edi), %esp
|
|
|
|
addl $PAGE_SIZE, %esp
|
|
|
|
2:
|
|
|
|
call *%edx
|
|
|
|
|
|
|
|
/* get the re-entry point of the peer system */
|
|
|
|
movl 0(%esp), %ebp
|
|
|
|
call 1f
|
|
|
|
1:
|
|
|
|
popl %ebx
|
|
|
|
subl $(1b - relocate_kernel), %ebx
|
|
|
|
movl CP_VA_CONTROL_PAGE(%ebx), %edi
|
|
|
|
lea PAGE_SIZE(%ebx), %esp
|
|
|
|
movl CP_PA_SWAP_PAGE(%ebx), %eax
|
|
|
|
movl CP_PA_BACKUP_PAGES_MAP(%ebx), %edx
|
|
|
|
pushl %eax
|
|
|
|
pushl %edx
|
|
|
|
call swap_pages
|
|
|
|
addl $8, %esp
|
|
|
|
movl CP_PA_PGD(%ebx), %eax
|
|
|
|
movl %eax, %cr3
|
|
|
|
movl %cr0, %eax
|
2013-04-28 03:22:32 +04:00
|
|
|
orl $X86_CR0_PG, %eax
|
2008-07-26 06:45:07 +04:00
|
|
|
movl %eax, %cr0
|
|
|
|
lea PAGE_SIZE(%edi), %esp
|
|
|
|
movl %edi, %eax
|
|
|
|
addl $(virtual_mapped - relocate_kernel), %eax
|
|
|
|
pushl %eax
|
|
|
|
ret
|
|
|
|
|
|
|
|
virtual_mapped:
|
|
|
|
movl CR4(%edi), %eax
|
|
|
|
movl %eax, %cr4
|
|
|
|
movl CR3(%edi), %eax
|
|
|
|
movl %eax, %cr3
|
|
|
|
movl CR0(%edi), %eax
|
|
|
|
movl %eax, %cr0
|
|
|
|
movl ESP(%edi), %esp
|
|
|
|
movl %ebp, %eax
|
|
|
|
|
|
|
|
popf
|
|
|
|
popl %ebp
|
|
|
|
popl %edi
|
|
|
|
popl %esi
|
|
|
|
popl %ebx
|
|
|
|
ret
|
|
|
|
|
2005-06-26 01:57:56 +04:00
|
|
|
/* Do the copies */
|
2008-07-26 06:45:07 +04:00
|
|
|
swap_pages:
|
|
|
|
movl 8(%esp), %edx
|
|
|
|
movl 4(%esp), %ecx
|
|
|
|
pushl %ebp
|
|
|
|
pushl %ebx
|
|
|
|
pushl %edi
|
|
|
|
pushl %esi
|
|
|
|
movl %ecx, %ebx
|
2005-06-26 01:57:56 +04:00
|
|
|
jmp 1f
|
|
|
|
|
|
|
|
0: /* top, read another word from the indirection page */
|
|
|
|
movl (%ebx), %ecx
|
|
|
|
addl $4, %ebx
|
|
|
|
1:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 23:55:32 +03:00
|
|
|
testb $0x1, %cl /* is it a destination page */
|
2005-06-26 01:57:56 +04:00
|
|
|
jz 2f
|
|
|
|
movl %ecx, %edi
|
|
|
|
andl $0xfffff000, %edi
|
|
|
|
jmp 0b
|
|
|
|
2:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 23:55:32 +03:00
|
|
|
testb $0x2, %cl /* is it an indirection page */
|
2005-06-26 01:57:56 +04:00
|
|
|
jz 2f
|
|
|
|
movl %ecx, %ebx
|
|
|
|
andl $0xfffff000, %ebx
|
|
|
|
jmp 0b
|
|
|
|
2:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 23:55:32 +03:00
|
|
|
testb $0x4, %cl /* is it the done indicator */
|
2005-06-26 01:57:56 +04:00
|
|
|
jz 2f
|
|
|
|
jmp 3f
|
|
|
|
2:
|
x86/asm: Optimize unnecessarily wide TEST instructions
By the nature of the TEST operation, it is often possible to test
a narrower part of the operand:
"testl $3, mem" -> "testb $3, mem",
"testq $3, %rcx" -> "testb $3, %cl"
This results in shorter instructions, because the TEST instruction
has no sign-entending byte-immediate forms unlike other ALU ops.
Note that this change does not create any LCP (Length-Changing Prefix)
stalls, which happen when adding a 0x66 prefix, which happens when
16-bit immediates are used, which changes such TEST instructions:
[test_opcode] [modrm] [imm32]
to:
[0x66] [test_opcode] [modrm] [imm16]
where [imm16] has a *different length* now: 2 bytes instead of 4.
This confuses the decoder and slows down execution.
REX prefixes were carefully designed to almost never hit this case:
adding REX prefix does not change instruction length except MOVABS
and MOV [addr],RAX instruction.
This patch does not add instructions which would use a 0x66 prefix,
code changes in assembly are:
-48 f7 07 01 00 00 00 testq $0x1,(%rdi)
+f6 07 01 testb $0x1,(%rdi)
-48 f7 c1 01 00 00 00 test $0x1,%rcx
+f6 c1 01 test $0x1,%cl
-48 f7 c1 02 00 00 00 test $0x2,%rcx
+f6 c1 02 test $0x2,%cl
-41 f7 c2 01 00 00 00 test $0x1,%r10d
+41 f6 c2 01 test $0x1,%r10b
-48 f7 c1 04 00 00 00 test $0x4,%rcx
+f6 c1 04 test $0x4,%cl
-48 f7 c1 08 00 00 00 test $0x8,%rcx
+f6 c1 08 test $0x8,%cl
Linus further notes:
"There are no stalls from using 8-bit instruction forms.
Now, changing from 64-bit or 32-bit 'test' instructions to 8-bit ones
*could* cause problems if it ends up having forwarding issues, so that
instead of just forwarding the result, you end up having to wait for
it to be stable in the L1 cache (or possibly the register file). The
forwarding from the store buffer is simplest and most reliable if the
read is done at the exact same address and the exact same size as the
write that gets forwarded.
But that's true only if:
(a) the write was very recent and is still in the write queue. I'm
not sure that's the case here anyway.
(b) on at least most Intel microarchitectures, you have to test a
different byte than the lowest one (so forwarding a 64-bit write
to a 8-bit read ends up working fine, as long as the 8-bit read
is of the low 8 bits of the written data).
A very similar issue *might* show up for registers too, not just
memory writes, if you use 'testb' with a high-byte register (where
instead of forwarding the value from the original producer it needs to
go through the register file and then shifted). But it's mainly a
problem for store buffers.
But afaik, the way Denys changed the test instructions, neither of the
above issues should be true.
The real problem for store buffer forwarding tends to be "write 8
bits, read 32 bits". That can be really surprisingly expensive,
because the read ends up having to wait until the write has hit the
cacheline, and we might talk tens of cycles of latency here. But
"write 32 bits, read the low 8 bits" *should* be fast on pretty much
all x86 chips, afaik."
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Drewry <wad@chromium.org>
Link: http://lkml.kernel.org/r/1425675332-31576-1-git-send-email-dvlasenk@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-06 23:55:32 +03:00
|
|
|
testb $0x8, %cl /* is it the source indicator */
|
2005-06-26 01:57:56 +04:00
|
|
|
jz 0b /* Ignore it otherwise */
|
|
|
|
movl %ecx, %esi /* For every source page do a copy */
|
|
|
|
andl $0xfffff000, %esi
|
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
movl %edi, %eax
|
|
|
|
movl %esi, %ebp
|
|
|
|
|
|
|
|
movl %edx, %edi
|
2005-06-26 01:57:56 +04:00
|
|
|
movl $1024, %ecx
|
|
|
|
rep ; movsl
|
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
movl %ebp, %edi
|
|
|
|
movl %eax, %esi
|
|
|
|
movl $1024, %ecx
|
|
|
|
rep ; movsl
|
2005-06-26 01:57:56 +04:00
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
movl %eax, %edi
|
|
|
|
movl %edx, %esi
|
|
|
|
movl $1024, %ecx
|
|
|
|
rep ; movsl
|
2005-06-26 01:57:56 +04:00
|
|
|
|
2008-07-26 06:45:07 +04:00
|
|
|
lea PAGE_SIZE(%ebp), %esi
|
|
|
|
jmp 0b
|
|
|
|
3:
|
|
|
|
popl %esi
|
|
|
|
popl %edi
|
|
|
|
popl %ebx
|
|
|
|
popl %ebp
|
2005-06-26 01:57:56 +04:00
|
|
|
ret
|
2008-08-15 11:40:23 +04:00
|
|
|
|
|
|
|
.globl kexec_control_code_size
|
|
|
|
.set kexec_control_code_size, . - relocate_kernel
|