From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
Cc: devel@openvz.org
Subject: [Devel] [PATCH hci-8.1 v3 0/5] x86/ve: CPUID override follow-ups: arm at once, prefixes, selftests
Date: Tue, 06 Oct 2026 22:44:31 +0200 [thread overview]
Message-ID: <20261006-b4-prep-khorenko-vstor-148656-cpuid-v3-0-16141b8ca07d@virtuozzo.com> (raw)
VSTOR-148656, every Container start dying with SIGSEGV once
/proc/vz/cpuid_override is non-empty, is fixed in 22.8 by 07338fbae5a3
("x86/traps: emulate CPUID faults for user tasks in
exc_general_protection()"). Working on it turned up two more defects in
the same feature, and the fact that nothing had ever exercised it. This
series takes care of those. None of them is a 22.x regression, all have
been there since the vz9 port.
Patch 2: ve_setup_task() only sets TIF_CPUID_OVERRIDE, the MSR follows
at the next context switch. A task entering a VE through unshare() or
setns() executes CPUID natively until it is scheduled out and sees the
host values. set_cpuid_override() flips the MSR synchronously for the
current task, the way disable_cpuid() does.
Patch 4: check_cpuid_fault() compares two bytes at ip with 0f a2. A
CPUID with a legacy or REX prefix faults the same way, but the handler
sees the prefix and the task gets SIGSEGV. Use the instruction decoder,
as fixup_umip_exception() does, and advance ip by the decoded length.
Patches 1, 3, 5: selftests/ve/ve_cpuid_override_test. Each kernel patch
gets its own case. The test saves and restores the table around every
case and tears down in the parent, because the kselftest harness skips
a child-side teardown after a failed ASSERT.
Tested on sqvm2-4060, the node of the failing CI run (Broadwell VM with
cpuid_fault, cpupools-features 9.1.7, so the table is armed at every
Container start). With only the 22.8 fix, cases 3 and 4 fail the way
their patches describe: host values, and a child killed by signal 11.
With the whole series all four cases pass, repeatedly and on a
non-empty table, and the vzctl-pytest start cases from the original
ticket pass as well.
https://virtuozzo.atlassian.net/browse/VSTOR-148843
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
Changes in v3:
- Patch 1: a saved table the kernel cannot take back in one write (a
page or more as printed) fails the setup instead of being silently
left behind by a failed restore; writes replace the table, so there
is no way to restore it in pieces (Sashiko).
- Patch 1: the child pid lives in the fixture and the parent-side
teardown kills a child that a failed ASSERT left stopped in the VE
cgroup, otherwise destroy_ve() fails with EBUSY (Sashiko).
- Patch 1: the Makefile keeps ARCH untouched and decides on a private
variable, lib.mk picks the clang target by ARCH being empty (Sashiko).
- Link to v2: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-cpuid-v2-0-f6d1192c7d60@virtuozzo.com
Changes in v2:
- Patch 1: the child stops itself with SIGSTOP after entering the VE
and the parent resumes it, so faulting is armed by a real context
switch; the pipe handshake, whose read could return without sleeping,
is gone (Sashiko).
- Patch 1: setup creates the VE cgroup last, so a failed ASSERT in
setup leaves nothing behind; a failed restore in teardown is logged
(Sashiko).
- Patch 1: drop the EAX comparison after the fallback to hardware, the
child is not pinned and hybrid CPUs may differ per core (Sashiko).
- Patch 1: build the test on x86 only, add the binary to .gitignore
(Sashiko).
- Patch 3: the no-reschedule case repeats the sequence, a tick can
still preempt the child in the window; with the handshake gone a
child that dies before reporting is reaped where the result is read
and its signal logged (Sashiko).
- Retested on sqvm2-2084 with the whole series: all cases pass and the
table is restored; on sqvm2-4060 with the stock kernel all cases fail
with the expected diagnostics.
- Link to v1: http://lore.virtuozzo.com/20261006-b4-prep-khorenko-vstor-148656-cpuid-v1-0-741609f4f03a@virtuozzo.com
---
Konstantin Khorenko (5):
selftests/ve: check CPUID override emulation for VE tasks
x86/ve: enable CPUID faulting at once when the current task enters a VE
selftests/ve: check CPUID override right after entering a VE
x86/traps: decode the faulting CPUID with the instruction decoder
selftests/ve: check CPUID override emulation for a prefixed CPUID
arch/x86/kernel/process.c | 12 +
arch/x86/kernel/traps.c | 16 +-
include/linux/cpuid_override.h | 3 +
kernel/ve/ve.c | 2 +-
tools/testing/selftests/ve/.gitignore | 1 +
tools/testing/selftests/ve/Makefile | 10 +
.../testing/selftests/ve/ve_cpuid_override_test.c | 300 +++++++++++++++++++++
7 files changed, 337 insertions(+), 7 deletions(-)
---
base-commit: f5d1fdcfffe101fe2bafa7df09d95d2e811c5c5e
change-id: 20261006-b4-prep-khorenko-vstor-148656-cpuid-a5c5993e1f83
Best regards,
--
Konstantin Khorenko <khorenko@virtuozzo.com>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next reply other threads:[~2026-10-06 20:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 20:44 Konstantin Khorenko [this message]
2026-10-06 20:44 ` [Devel] [PATCH hci-8.1 v3 1/5] selftests/ve: check CPUID override emulation for VE tasks Konstantin Khorenko
2026-10-06 20:52 ` no-reply
2026-10-06 20:44 ` [Devel] [PATCH hci-8.1 v3 2/5] x86/ve: enable CPUID faulting at once when the current task enters a VE Konstantin Khorenko
2026-10-06 20:49 ` no-reply
2026-10-06 20:44 ` [Devel] [PATCH hci-8.1 v3 3/5] selftests/ve: check CPUID override right after entering " Konstantin Khorenko
2026-10-06 20:50 ` no-reply
2026-10-06 20:44 ` [Devel] [PATCH hci-8.1 v3 4/5] x86/traps: decode the faulting CPUID with the instruction decoder Konstantin Khorenko
2026-10-06 20:51 ` no-reply
2026-10-06 20:44 ` [Devel] [PATCH hci-8.1 v3 5/5] selftests/ve: check CPUID override emulation for a prefixed CPUID Konstantin Khorenko
2026-10-06 20:52 ` no-reply
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=20261006-b4-prep-khorenko-vstor-148656-cpuid-v3-0-16141b8ca07d@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=devel@openvz.org \
--cc=ptikhomirov@virtuozzo.com \
--cc=vasileios.almpanis@virtuozzo.com \
/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