From: "tip-bot2 for Borislav Petkov (AMD)" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Daniel Verkamp <dverkamp@chromium.org>,
Jiri Slaby <jirislaby@kernel.org>,
"Borislav Petkov (AMD)" <bp@alien8.de>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/alternatives] x86/lib/memmove: Decouple ERMS from FSRM
Date: Sat, 13 May 2023 13:03:48 -0000 [thread overview]
Message-ID: <168398302855.404.16319361795751047208.tip-bot2@tip-bot2> (raw)
In-Reply-To: <yK0dyzI0MMdTie@zn.tnic>
The following commit has been merged into the x86/alternatives branch of tip:
Commit-ID: 14e4ec9c3e9164c6719f98d8a3065c487be2aaa5
Gitweb: https://git.kernel.org/tip/14e4ec9c3e9164c6719f98d8a3065c487be2aaa5
Author: Borislav Petkov (AMD) <bp@alien8.de>
AuthorDate: Sun, 26 Feb 2023 21:04:26 +01:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Wed, 10 May 2023 14:51:56 +02:00
x86/lib/memmove: Decouple ERMS from FSRM
Up until now it was perceived that FSRM is an improvement to ERMS and
thus it was made dependent on latter.
However, there are AMD BIOSes out there which allow for disabling of
either features and thus preventing kernels from booting due to the CMP
disappearing and thus breaking the logic in the memmove() function.
Similar observation happens on some VM migration scenarios.
Patch the proper sequences depending on which feature is enabled.
Reported-by: Daniel Verkamp <dverkamp@chromium.org>
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/Y/yK0dyzI0MMdTie@zn.tnic
---
arch/x86/lib/memmove_64.S | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 0266186..0559b20 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -38,10 +38,12 @@ SYM_FUNC_START(__memmove)
cmp %rdi, %r8
jg 2f
- /* FSRM implies ERMS => no length checks, do the copy directly */
+#define CHECK_LEN cmp $0x20, %rdx; jb 1f
+#define MEMMOVE_BYTES movq %rdx, %rcx; rep movsb; RET
.Lmemmove_begin_forward:
- ALTERNATIVE "cmp $0x20, %rdx; jb 1f", "", X86_FEATURE_FSRM
- ALTERNATIVE "", "jmp .Lmemmove_erms", X86_FEATURE_ERMS
+ ALTERNATIVE_2 __stringify(CHECK_LEN), \
+ __stringify(CHECK_LEN; MEMMOVE_BYTES), X86_FEATURE_ERMS, \
+ __stringify(MEMMOVE_BYTES), X86_FEATURE_FSRM
/*
* movsq instruction have many startup latency
@@ -207,11 +209,6 @@ SYM_FUNC_START(__memmove)
movb %r11b, (%rdi)
13:
RET
-
-.Lmemmove_erms:
- movq %rdx, %rcx
- rep movsb
- RET
SYM_FUNC_END(__memmove)
EXPORT_SYMBOL(__memmove)
parent reply other threads:[~2023-05-13 13:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <yK0dyzI0MMdTie@zn.tnic>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=168398302855.404.16319361795751047208.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=bp@alien8.de \
--cc=dverkamp@chromium.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®