[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v10 28/38] x86/fred: FRED entry/exit and dispatch code
- To: Xin Li <xin3.li@xxxxxxxxx>, linux-doc@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-edac@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Nikolay Borisov <nik.borisov@xxxxxxxx>
- Date: Thu, 21 Sep 2023 12:48:17 +0300
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tteY01czoQxqLsrAQIn/17VJLh97CKwm9ZSf1j+VPDg=; b=cO+U7Hig+ztMeshLsvKEewwoT1sJLvm1bnUJSfGYaNZ/FNbotfrYVkjKDMY+Y3K8BdQqdfuKC7TRsQvpf1DalotHTff1TStDd84nNE3If2Ye9Cff06Y1ijUEe3OkujDfMgM130fMCcZ4ZQWhwOkS3LjDIoOJPlI82+PEVYfBKMb0vkopNSeblwni5NVeO47B2KcijGVHrfiAi4iLa8O4fgawAElYzAae+/kS80r+agf+BYSLjGgulxfEoKMFP5CARFJpg1SU3tQILynLctAENLw+lsBXf4GXy0S3BE1wHO2MD8wjVfLr3yD8cKCmz0DLBxkW5+dTyucbwH4KIfct3A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cz4aKIUi+IRUoFZMpKUTnvuhfrHrua6gv2KuTZaluP+m5/8MV5mnp8f/IozduEPs7PDZienKFryI93yiZZQcvrSNbpgSNkOuz+rhk09uq4BF77gqqglEmVv0UK2YqOoMbIS1zED4dFdJdNyLu0M+XPQUkvKg0bxWCh+mh/4H7KD7FW6Bo712DOOld/AJoCjZiRe9Gxx31tN2kJoIUNo8V5evgcJFzHiHpkMyf1W9XicfETvxYIbo8RefgLt+FbwcMLbgMcY7d0gYh2siIYD+cxogx8Sf0XG05czv9bRlhi/9oX7HJxDRo0lg8hEtoKKMW4VcDir2nK6nimCOvtmWkg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: tglx@xxxxxxxxxxxxx, mingo@xxxxxxxxxx, bp@xxxxxxxxx, dave.hansen@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, hpa@xxxxxxxxx, luto@xxxxxxxxxx, pbonzini@xxxxxxxxxx, seanjc@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, jgross@xxxxxxxx, ravi.v.shankar@xxxxxxxxx, mhiramat@xxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, jiangshanlai@xxxxxxxxx
- Delivery-date: Thu, 21 Sep 2023 09:48:40 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 14.09.23 г. 7:47 ч., Xin Li wrote:
From: "H. Peter Anvin (Intel)" <hpa@xxxxxxxxx>
The code to actually handle kernel and event entry/exit using
FRED. It is split up into two files thus:
- entry_64_fred.S contains the actual entrypoints and exit code, and
saves and restores registers.
- entry_fred.c contains the two-level event dispatch code for FRED.
The first-level dispatch is on the event type, and the second-level
is on the event vector.
Originally-by: Megha Dey <megha.dey@xxxxxxxxx>
Signed-off-by: H. Peter Anvin (Intel) <hpa@xxxxxxxxx>
Co-developed-by: Xin Li <xin3.li@xxxxxxxxx>
Tested-by: Shan Kang <shan.kang@xxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Signed-off-by: Xin Li <xin3.li@xxxxxxxxx>
---
Changes since v9:
* Don't use jump tables, indirect jumps are expensive (Thomas Gleixner).
* Except NMI/#DB/#MCE, FRED really can share the exception handlers
with IDT (Thomas Gleixner).
* Avoid the sysvec_* idt_entry muck, do it at a central place, reuse code
instead of blindly copying it, which breaks the performance optimized
sysvec entries like reschedule_ipi (Thomas Gleixner).
* Add asm_ prefix to FRED asm entry points (Thomas Gleixner).
Changes since v8:
* Don't do syscall early out in fred_entry_from_user() before there are
proper performance numbers and justifications (Thomas Gleixner).
* Add the control exception handler to the FRED exception handler table
(Thomas Gleixner).
* Add ENDBR to the FRED_ENTER asm macro.
* Reflect the FRED spec 5.0 change that ERETS and ERETU add 8 to %rsp
before popping the return context from the stack.
Changes since v1:
* Initialize a FRED exception handler to fred_bad_event() instead of NULL
if no FRED handler defined for an exception vector (Peter Zijlstra).
* Push calling irqentry_{enter,exit}() and instrumentation_{begin,end}()
down into individual FRED exception handlers, instead of in the dispatch
framework (Peter Zijlstra).
---
arch/x86/entry/Makefile | 5 +-
arch/x86/entry/entry_64_fred.S | 52 ++++++
arch/x86/entry/entry_fred.c | 230 ++++++++++++++++++++++++++
arch/x86/include/asm/asm-prototypes.h | 1 +
arch/x86/include/asm/fred.h | 6 +
5 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/entry/entry_64_fred.S
create mode 100644 arch/x86/entry/entry_fred.c
<snip>
+
+static noinstr void fred_intx(struct pt_regs *regs)
+{
+ switch (regs->fred_ss.vector) {
+ /* INT0 */
+ case X86_TRAP_OF:
+ exc_overflow(regs);
+ return;
+
+ /* INT3 */
+ case X86_TRAP_BP:
+ exc_int3(regs);
+ return;
+
+ /* INT80 */
+ case IA32_SYSCALL_VECTOR:
+ if (likely(IS_ENABLED(CONFIG_IA32_EMULATION))) {
Since future kernels will support boottime toggling of whether 32bit
syscall interface should be enabled or not as per:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/entry&id=1da5c9bc119d3a749b519596b93f9b2667e93c4a
It will make more sense to replace this with ia32_enabled() invocation.
I guess this could be done as a follow-up patch based on when this is
merged as the ia32_enbaled changes are going to be merged in 6.7.
+ /* Save the syscall number */
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_int80_syscall_32(regs);
+ return;
+ }
+ fallthrough;
+
+ default:
+ exc_general_protection(regs, 0);
+ return;
+ }
+}
+
+static __always_inline void fred_other(struct pt_regs *regs)
+{
+ /* The compiler can fold these conditions into a single test */
+ if (likely(regs->fred_ss.vector == FRED_SYSCALL && regs->fred_ss.lm)) {
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_syscall_64(regs, regs->orig_ax);
+ return;
+ } else if (likely(IS_ENABLED(CONFIG_IA32_EMULATION) &&
Ditto
+ regs->fred_ss.vector == FRED_SYSENTER &&
+ !regs->fred_ss.lm)) {
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_fast_syscall_32(regs);
+ return;
+ } else {
+ exc_invalid_op(regs);
+ return;
+ }
+}
+
<snip>
|