OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
To: devel@openvz.org
Subject: [Devel] [PATCH RK VZ10] x86/traps: emulate CPUID faults for user tasks in exc_general_protection()
Date: Mon,  2 Nov 2026 11:04:32 +0100	[thread overview]
Message-ID: <20261102100432.15867-1-vladimir.riabchun@virtuozzo.com> (raw)

A non-empty /proc/vz/cpuid_override table makes ve_setup_task() set
TIF_CPUID_OVERRIDE on every task entering a VE, so the CPU raises #GP
on each CPUID the task executes and check_cpuid_fault() is supposed
to emulate the instruction with the table values.

The call sits after the user-mode branch of exc_general_protection(),
which ends in gp_user_force_sig_segv() and goto exit, so it is reached
only for a kernel-mode #GP, where CPUID never faults. Every Container
task dies with SIGSEGV on the first CPUID of glibc init_cpu_features()
instead of getting the override:

traps: bash[179661] general protection fault ip:7fa8b470357f ... in
ld-linux-x86-64.so.2[1857f,...]

The original vz8 patch was written for 4.18, where do_general_protection()
handled kernel mode first and the call landed on the user path. The vz9
port kept the relative position after upstream had reversed the order of
the two branches.

Move the call into the user-mode branch, before the signal is sent.
check_cpuid_fault() still declines tasks with TIF_NOCPUID, so
arch_prctl(ARCH_SET_CPUID, 0) keeps its SIGSEGV semantics.

Fixes: 1033fe455434 ("arch/x86: introduce cpuid override")
https://virtuozzo.atlassian.net/browse/VSTOR-148656

Feature: x86: cpu pools (cpuid override)
Reviewed-by: Vasileios Almpanis vasileios.almpanis@virtuozzo.com
Link: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-just-cpuid-v1-1-6f2a2a6deef3@virtuozzo.com
Signed-off-by: Konstantin Khorenko khorenko@virtuozzo.com

ReadyKernel-specific changes:
We can't patch exc_general_protection directly, so we need another place.
fixup_vdso_exception is not inlined and is the last check on user-mode path.
We can perform CPUID fault check inside fixup_vdso_exception on false path,
that will be the closes reproduction of fix behavior.

RK_BUG: VSTOR-152668
RK_CHANGELOG: Fix GP handler to support CPUID emulation and allow container start.

Signed-off-by: Vladimir Riabchun vladimir.riabchun@virtuozzo.com
---
 arch/x86/entry/vdso/extable.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/extable.c b/arch/x86/entry/vdso/extable.c
index afcf5b65beef..ca8c184925ec 100644
--- a/arch/x86/entry/vdso/extable.c
+++ b/arch/x86/entry/vdso/extable.c
@@ -9,6 +9,30 @@ struct vdso_exception_table_entry {
 	int insn, fixup;
 };
 
+static int check_cpuid_fault(struct pt_regs *regs, long error_code)
+{
+	unsigned long addr;
+	unsigned short opcode;
+
+	if (error_code != 0)
+		return 0;
+
+	if (test_thread_flag(TIF_NOCPUID))
+		return 0;
+
+	addr = convert_ip_to_linear(current, regs);
+	if (get_user(opcode, (unsigned short __user *)addr))
+		return 0;
+
+	if (opcode != 0xa20f)
+		return 0;
+
+	do_cpuid_fault(regs);
+
+	regs->ip += 2;
+	return 1;
+}
+
 bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
 			  unsigned long error_code, unsigned long fault_addr)
 {
@@ -26,7 +50,7 @@ bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
 		return false;
 
 	if (!current->mm->context.vdso)
-		return false;
+		goto try_fixup_cupid;
 
 	base =  (unsigned long)current->mm->context.vdso + image->extable_base;
 	nr_entries = image->extable_len / (sizeof(*extable));
@@ -42,5 +66,10 @@ bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
 		}
 	}
 
+try_fixup_cupid:
+	/* Only exc_general_protection can go this way */
+	if (trapnr == X86_TRAP_GP && check_cpuid_fault(regs, error_code))
+		return true;
+
 	return false;
 }
-- 
2.52.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

             reply	other threads:[~2026-11-02 10:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 10:04 Vladimir Riabchun [this message]
2026-11-02 10:11 ` no-reply
2026-11-02 10:20 ` Vasileios Almpanis
2026-11-02 15:15 ` Pavel Tikhomirov

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=20261102100432.15867-1-vladimir.riabchun@virtuozzo.com \
    --to=vladimir.riabchun@virtuozzo.com \
    --cc=devel@openvz.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