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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox