From: no-reply@sashiko.virtuozzo.com
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>,
Konstantin Khorenko <khorenko@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v5 5/5] selftests/ve: check CPUID override emulation for a prefixed CPUID
Date: Tue, 6 Oct 2026 23:03:08 +0000 [thread overview]
Message-ID: <010701a11374de67-f21d3b76-2b19-4841-937d-f494eab4973c-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261007-b4-prep-khorenko-vstor-148656-cpuid-v5-5-652c5c9e56da@virtuozzo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests/ve: do_cpuid_prefixed() 32-bit xchg of ebx truncates callee-saved RBX on x86_64
--
commit a68470c5110f8f0b39dbfe6d2c82d537ef16105e
Author: Konstantin Khorenko <khorenko@virtuozzo.com>
selftests/ve: check CPUID override emulation for a prefixed CPUID
This commit adds a selftest that executes CPUID with an operand-size
prefix (0x66) and expects the overridden table values. It adds a
do_cpuid_prefixed() helper, a prefixed flag in struct child_ctx, and a new
test prefixed_cpuid_is_emulated.
Link: https://virtuozzo.atlassian.net/browse/VSTOR-148843
> diff --git a/tools/testing/selftests/ve/ve_cpuid_override_test.c b/tools/testing/selftests/ve/ve_cpuid_override_test.c
> --- a/tools/testing/selftests/ve/ve_cpuid_override_test.c
> +++ b/tools/testing/selftests/ve/ve_cpuid_override_test.c
[ ... ]
> +/* CPUID with an operand-size prefix, which the CPU accepts and ignores. */
> +static void do_cpuid_prefixed(unsigned int leaf, struct cpuid_regs *r)
> +{
> + /* ebx is the PIC base on i386; swap it out like <cpuid.h> does. */
> + asm volatile("xchg %%ebx, %1\n\t"
> + ".byte 0x66, 0x0f, 0xa2\n\t"
> + "xchg %%ebx, %1"
> + : "=a" (r->eax), "=&r" (r->ebx), "=c" (r->ecx), "=d" (r->edx)
> + : "a" (leaf), "c" (0));
> +}
[Severity: Medium]
Can this asm corrupt RBX on x86_64?
The i386 PIC workaround is applied unconditionally. On x86_64, a 32-bit
"xchg %%ebx, %1" zero-extends into RBX, and the closing "xchg %%ebx, %1"
only restores the low 32 bits.
RBX is callee-saved and is not listed as clobbered or tied to an operand in
do_cpuid_prefixed(). If the compiler keeps a 64-bit value there, the upper
half is lost.
Since do_cpuid_prefixed() is static, it is likely inlined into
cpuid_child(), which uses ctx and &r right after the asm:
if (ctx->prefixed)
do_cpuid_prefixed(CPUID_LEAF, &r);
else
do_cpuid(CPUID_LEAF, &r);
if (write(ctx->result_pipe[1], &r, sizeof(r)) != sizeof(r))
If ctx or &r lives in RBX, could the write() call or the ctx dereference
fault? That would show up as a SIGSEGV, which is the same symptom this
test uses to detect missing kernel emulation, so the failure could be
misattributed.
Whether a live value actually sits in RBX depends on the compiler version,
optimization level and register allocation.
Would it make sense to guard the swap with #if defined(__i386__) &&
defined(__PIC__), and use a plain cpuid with a "=b" output otherwise?
Declaring rbx as clobbered or using a 64-bit xchg would also work.
--
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261007-b4-prep-khorenko-vstor-148656-cpuid-v5-0-652c5c9e56da@virtuozzo.com?part=5
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
prev parent reply other threads:[~2026-10-06 23:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 22:54 [Devel] [PATCH hci-8.1 v5 0/5] x86/ve: CPUID override follow-ups: arm at once, prefixes, selftests Konstantin Khorenko
2026-10-06 22:54 ` [Devel] [PATCH hci-8.1 v5 1/5] selftests/ve: check CPUID override emulation for VE tasks Konstantin Khorenko
2026-10-06 23:03 ` no-reply
2026-10-06 22:54 ` [Devel] [PATCH hci-8.1 v5 2/5] x86/ve: enable CPUID faulting at once when the current task enters a VE Konstantin Khorenko
2026-10-06 22:59 ` no-reply
2026-10-06 22:54 ` [Devel] [PATCH hci-8.1 v5 3/5] selftests/ve: check CPUID override right after entering " Konstantin Khorenko
2026-10-06 23:00 ` no-reply
2026-10-06 22:54 ` [Devel] [PATCH hci-8.1 v5 4/5] x86/traps: decode the faulting CPUID with the instruction decoder Konstantin Khorenko
2026-10-06 23:01 ` no-reply
2026-10-06 22:54 ` [Devel] [PATCH hci-8.1 v5 5/5] selftests/ve: check CPUID override emulation for a prefixed CPUID Konstantin Khorenko
2026-10-06 23:03 ` no-reply [this message]
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=010701a11374de67-f21d3b76-2b19-4841-937d-f494eab4973c-000000@eu-central-1.amazonses.com \
--to=no-reply@sashiko.virtuozzo.com \
--cc=devel@openvz.org \
--cc=khorenko@virtuozzo.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.