From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v6 1/5] selftests/ve: check CPUID override emulation for VE tasks
Date: Wed, 7 Oct 2026 15:16:25 +0200 [thread overview]
Message-ID: <6bfa2d88-6532-453f-9b8c-9ba924d1b8fb@virtuozzo.com> (raw)
In-Reply-To: <010701a116405519-8d9fc189-e7d8-494f-83f7-991983ed4b6d-000000@eu-central-1.amazonses.com>
On 10/7/26 14:04, no-reply@sashiko.virtuozzo.com wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] selftests/ve: arch gate runs $(CC) -dumpmachine before lib.mk sets CC
> --
>
> commit de465213924e8ab9123a95613dab45358f011917
> Author: Konstantin Khorenko <khorenko@virtuozzo.com>
>
> selftests/ve: check CPUID override emulation for VE tasks
>
> This adds ve_cpuid_override_test, which writes a one-entry
> /proc/vz/cpuid_override table and compares what a task in a fresh VE and
> the host see for CPUID leaf 1. A second test flushes the table after the
> task was armed and expects the hardware value back. The test is added to
> the ve selftests Makefile for x86-64 builds only.
>
> Link: https://virtuozzo.atlassian.net/browse/VSTOR-148843
>
>> diff --git a/tools/testing/selftests/ve/Makefile b/tools/testing/selftests/ve/Makefile
>> index c6efe7c4b4fb..3f494a49270e 100644
>> --- a/tools/testing/selftests/ve/Makefile
>> +++ b/tools/testing/selftests/ve/Makefile
>> @@ -6,4 +6,10 @@ TEST_GEN_PROGS += ve_ns_owner_test
>> TEST_GEN_PROGS += ve_perms_test
>> TEST_GEN_PROGS += ve_mount_accounting_test
>>
>> +# CPUID faulting is x86-64 only. ARCH says "x86" for 32-bit too and lib.mk
>> +# picks the clang target by its emptiness, so decide by the compiler.
>> +ifneq ($(filter x86_64-%,$(shell $(CC) -dumpmachine 2>/dev/null)),)
>
> [Severity: Low]
> Is $(CC) the right compiler to query at this point? This ifneq is expanded
> while the Makefile is being parsed, before the include of ../lib.mk, and
> lib.mk is where the real compiler is assigned:
>
> tools/testing/selftests/lib.mk:
> CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as (LLVM builds)
> CC := $(CROSS_COMPILE)gcc (otherwise)
>
> Until then $(CC) is make's built-in "cc", unless CC was set on the command
> line or in the environment.
>
> For example, with a cross build from an x86_64 host:
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
>
> "cc -dumpmachine" prints x86_64-linux-gnu, so the filter matches and
> ve_cpuid_override_test is added to TEST_GEN_PROGS. It is then built with
> the aarch64 compiler, where <cpuid.h> and __cpuid_count are not available,
> so the whole ve selftest directory fails to build.
>
> The reverse case also looks possible. On an arm64 host cross-building for
> x86_64, the test would be skipped.
>
> The comment above the check says it decides "by the compiler", and the
> commit message says "The test is built on x86-64 only". Neither seems to
> hold for cross builds.
>
> Could the check be done after including lib.mk, or be based on ARCH,
> SRCARCH or uname -m instead?
The observation is right: at that point $(CC) is still make's built-in
"cc", lib.mk assigns the real compiler only later. The check cannot move
below the include, though. lib.mk derives its rules from TEST_GEN_PROGS
while it is being parsed ("all: $(TEST_GEN_PROGS) ..." and the per-program
rules), so anything added to TEST_GEN_PROGS after the include is simply
not built.
The alternatives do not work either:
- ARCH cannot tell 32-bit from 64-bit x86: the top-level selftests
Makefile maps both i386 and x86_64 to "x86". Assigning ARCH ourselves
is out as well, lib.mk uses an empty ARCH to mean "the host target" for
LLVM=1 builds, and a value it has no CLANG_TARGET_FLAGS_ entry for
(e.g. "aarch64" from uname -m) makes it error out for the whole ve
directory. That was the v2 version of this gate, and the review rightly
rejected it.
- SRCARCH has the same granularity as ARCH.
- uname -m knows nothing about cross builds at all, so it is strictly
worse than asking a compiler.
What remains is a gap for cross builds only: the gate asks the host
compiler, so cross-building these selftests from an x86-64 host for
another architecture would add the test and fail on <cpuid.h>, and the
reverse would skip it. We do not cross build the vz selftests, the
feature under test exists on x86-64 only, and I would rather keep a
three-line gate than grow it to cover a configuration nobody runs. If a
cross build of tools/testing/selftests/ve ever becomes a thing, the gate
can be revisited then.
>
>> +TEST_GEN_PROGS += ve_cpuid_override_test
>> +endif
>> +
>> include ../lib.mk
>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-10-07 13:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 11:57 [Devel] [PATCH hci-8.1 v6 0/5] x86/ve: CPUID override follow-ups: arm at once, prefixes, selftests Konstantin Khorenko
2026-10-07 11:57 ` [Devel] [PATCH hci-8.1 v6 1/5] selftests/ve: check CPUID override emulation for VE tasks Konstantin Khorenko
2026-10-07 12:04 ` no-reply
2026-10-07 13:16 ` Konstantin Khorenko [this message]
2026-10-07 11:57 ` [Devel] [PATCH hci-8.1 v6 2/5] x86/ve: enable CPUID faulting at once when the current task enters a VE Konstantin Khorenko
2026-10-07 12:02 ` no-reply
2026-10-08 10:18 ` Vasileios Almpanis
2026-10-08 13:38 ` Konstantin Khorenko
2026-10-07 11:57 ` [Devel] [PATCH hci-8.1 v6 3/5] selftests/ve: check CPUID override right after entering " Konstantin Khorenko
2026-10-07 12:03 ` no-reply
2026-10-07 11:57 ` [Devel] [PATCH hci-8.1 v6 4/5] x86/traps: decode the faulting CPUID with the instruction decoder Konstantin Khorenko
2026-10-07 12:04 ` no-reply
2026-10-07 11:57 ` [Devel] [PATCH hci-8.1 v6 5/5] selftests/ve: check CPUID override emulation for a prefixed CPUID Konstantin Khorenko
2026-10-07 12:04 ` no-reply
2026-10-08 10:18 ` [Devel] [PATCH hci-8.1 v6 0/5] x86/ve: CPUID override follow-ups: arm at once, prefixes, selftests Vasileios Almpanis
2026-10-08 13:39 ` Konstantin Khorenko
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=6bfa2d88-6532-453f-9b8c-9ba924d1b8fb@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 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.