On Thu, 22 Aug 2024, Reinette Chatre wrote:
> Hi Ilpo,
>
> On 8/22/24 1:11 AM, Ilpo Järvinen wrote:
> > Building resctrl selftest fails on ARM because it uses __cpuid_count()
> > that fails the build with error:
> >
> > CC resctrl_tests
> > In file included from resctrl.h:24,
> > from cat_test.c:11:
> > In function 'arch_supports_noncont_cat',
> > inlined from 'noncont_cat_run_test' at cat_test.c:323:6:
> > ../kselftest.h:74:9: error: impossible constraint in 'asm'
> > 74 | __asm__ __volatile__ ("cpuid\n\t" \
> > | ^~~~~~~
> > cat_test.c:301:17: note: in expansion of macro '__cpuid_count'
> > 301 | __cpuid_count(0x10, 1, eax, ebx, ecx, edx);
> > | ^~~~~~~~~~~~~
> > ../kselftest.h:74:9: error: impossible constraint in 'asm'
> > 74 | __asm__ __volatile__ ("cpuid\n\t" \
> > | ^~~~~~~
> > cat_test.c:303:17: note: in expansion of macro '__cpuid_count'
> > 303 | __cpuid_count(0x10, 2, eax, ebx, ecx, edx);
> > | ^~~~~~~~~~~~~
> >
> > The resctrl selftest would run that code only on Intel CPUs but
> > as is, the code cannot be build at all.
> >
> > Provide an empty stub for __cpuid_count() if it is not supported to
> > allow build to succeed. The stub casts its arguments to void to avoid
> > causing variable unused warnings.
> >
> > Fixes: ae638551ab64 ("selftests/resctrl: Add non-contiguous CBMs CAT test")
> > Reported-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx>
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
> > Tested-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx>
> > Reviewed-by: Muhammad Usama Anjum <usama.anjum@xxxxxxxxxxxxx>
> > ---
> >
> > v2:
> > - Removed RFC & added Fixes and Tested-by
> > - Fixed the error message's line splits
> > - Noted down the reason for void casts in the stub
> > ---
> > tools/testing/selftests/kselftest.h | 6 ++++++
> > tools/testing/selftests/lib.mk | 4 ++++
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/tools/testing/selftests/kselftest.h
> > b/tools/testing/selftests/kselftest.h
> > index b8967b6e29d5..71593add1b39 100644
> > --- a/tools/testing/selftests/kselftest.h
> > +++ b/tools/testing/selftests/kselftest.h
> > @@ -70,10 +70,16 @@
> > * have __cpuid_count().
> > */
> > #ifndef __cpuid_count
> > +#ifdef HAVE_CPUID
> > #define __cpuid_count(level, count, a, b, c, d)
> > \
> > __asm__ __volatile__ ("cpuid\n\t" \
> > : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
> > : "0" (level), "2" (count))
> > +#else
> > +#define __cpuid_count(level, count, a, b, c, d) do {
> > \
> > + (void)a; (void)b; (void)c; (void)d; \
>
> The changelog states that this casting to void is done to avoid unused
> variable warnings.
> It is thus unexpected that not all parameters obtain the same casting
> treatment. It looks
> to me as though this only targets the resctrl selftest usage where the "level"
> and "count"
> parameters are constants.
The reason is entirely separate from what resctrl selftest expects.
a-d are output parameters for __cpuid_count(), they need this treatment
because they are typically not initialized but set by __cpuid_count() so
if __cpuid_count() is doing literally nothing, nothing touches those
four variables leading to unused variable warning.
> This is intended as a general kselftest solution so
> I believe
> that all parameters would need this casting to handle the cases where "level"
> and/or
> "count" are variables.
No, the same issue does not exist for input parameters because it would be
a valid warning. Passing uninitialized (and thus unused) input variable
is wrong so the calling logic is wrong. Thus, I don't see how the same
error could ever occur in a legitimate case for those two parameters.
> > +} while (0)
> > +#endif
> > #endif
> > /* define kselftest exit codes */
> > diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> > index d6edcfcb5be8..236db9b24037 100644
> > --- a/tools/testing/selftests/lib.mk
> > +++ b/tools/testing/selftests/lib.mk
> > @@ -199,6 +199,10 @@ clean: $(if $(TEST_GEN_MODS_DIR),clean_mods_dir)
> > # Build with _GNU_SOURCE by default
> > CFLAGS += -D_GNU_SOURCE=
> > +ifeq ($(ARCH),$(filter $(ARCH),x86 x86_64))
> > +CFLAGS += -DHAVE_CPUID=
> > +endif
>
> My earlier comment [1] when this work started remains. This technique depends
> on environment passing ARCH, which cannot be guaranteed. Looking at other
> usages of ARCH in the kselftest Makefiles it seems that the pattern is to
> initialize ARCH with "uname -m" if unset.
>
> > +
> > # Enables to extend CFLAGS and LDFLAGS from command line, e.g.
> > # make USERCFLAGS=-Werror USERLDFLAGS=-static
> > CFLAGS += $(USERCFLAGS)
>
> Reinette
>
> [1]
> https://lore.kernel.org/lkml/db16db55-5f68-484f-ba9f-3312b41bf426@xxxxxxxxx/
Ah, sorry. I'd missed that comment because it started mid-paragraph.
I wonder if I can safely touch ARCH or if there are caveats and it would
be better to use some other makefile variable.
--
i.
