[PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Maxime Chevallier (Netdev Foundation)]

Hi everyone, here's V2 for cross-compilation improvements for the
drivers/net/hw selftests.

Patch 1 fixes YNL cross compilation, while patch 2 deals with the
iou_zcrx check.

Jakub asked :

  I assume you don't actually have luring for your cross- env? Could we
  keep it simple and just declare luring as unavailable when cross
  compiling? Because the probing compilation rule is probably missing 
  more flags to make cross compilation work.

  Ignore if selftests using luring do actually work for you after this
  patch..

Turns out I did have liburing in the CC env (generated from Buildroot,
which supports liburing), and the cross-compiled liburing check worked
as expected :)

Tested on an aarch64 target, built on x86_64.

Thanks,

Maxime

Changes in V2:
 - Update the topic for patch 1
 - Update the CC construction for patch 2

V1: https://lore.kernel.org/r/20260901164200.1124343-1-maxime.chevallier@bootlin.com

Maxime Chevallier (Netdev Foundation) (2):
  tools: ynl: Allow cross-compiling ynl and associated tools
  selftests: drv-net: Use cross-compilation environment for the io_uring
    check

 tools/net/ynl/Makefile                          | 1 +
 tools/net/ynl/generated/Makefile                | 3 ++-
 tools/net/ynl/lib/Makefile                      | 3 ++-
 tools/net/ynl/tests/Makefile                    | 2 +-
 tools/net/ynl/ynltool/Makefile                  | 4 ++--
 tools/testing/selftests/drivers/net/hw/Makefile | 5 +++++
 6 files changed, 13 insertions(+), 5 deletions(-)

-- 
2.55.0

[PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools

[Maxime Chevallier (Netdev Foundation)]

The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to account for the cross-compiling options such as CROSS_COMPILE
or the LLVM-specific variables.

Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.

Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include

Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
---
V2: Fix subject, as per Jakub's review

 tools/net/ynl/Makefile           | 1 +
 tools/net/ynl/generated/Makefile | 3 ++-
 tools/net/ynl/lib/Makefile       | 3 ++-
 tools/net/ynl/tests/Makefile     | 2 +-
 tools/net/ynl/ynltool/Makefile   | 4 ++--
 5 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/tools/net/ynl/Makefile b/tools/net/ynl/Makefile
index 3cefe4ed96cb..8bf72c063e86 100644
--- a/tools/net/ynl/Makefile
+++ b/tools/net/ynl/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 include ../../scripts/Makefile.arch
+include ../../scripts/Makefile.include
 
 INSTALL	?= install
 prefix  ?= /usr
diff --git a/tools/net/ynl/generated/Makefile b/tools/net/ynl/generated/Makefile
index ea4128f612d6..5a186349b5a8 100644
--- a/tools/net/ynl/generated/Makefile
+++ b/tools/net/ynl/generated/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
-CC=gcc
+include ../../../scripts/Makefile.include
+
 CFLAGS += -std=gnu11 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow \
 	-I../lib/ -idirafter $(UAPI_PATH)
 ifeq ("$(DEBUG)","1")
diff --git a/tools/net/ynl/lib/Makefile b/tools/net/ynl/lib/Makefile
index 9b98c0599600..7b3eae89982f 100644
--- a/tools/net/ynl/lib/Makefile
+++ b/tools/net/ynl/lib/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
-CC=gcc
+include ../../../scripts/Makefile.include
+
 CFLAGS += -std=gnu11 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow
 ifeq ("$(DEBUG)","1")
   CFLAGS += -g -fsanitize=address -fsanitize=leak -static-libasan
diff --git a/tools/net/ynl/tests/Makefile b/tools/net/ynl/tests/Makefile
index 40827ca8e579..99ae7dcd6348 100644
--- a/tools/net/ynl/tests/Makefile
+++ b/tools/net/ynl/tests/Makefile
@@ -2,8 +2,8 @@
 # Makefile for YNL tests
 
 include ../Makefile.deps
+include ../../../scripts/Makefile.include
 
-CC=gcc
 CFLAGS += -std=gnu11 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow \
 	-I../lib/ -I../generated/ -I../../../testing/selftests/ \
 	-idirafter $(UAPI_PATH)
diff --git a/tools/net/ynl/ynltool/Makefile b/tools/net/ynl/ynltool/Makefile
index 48b0f32050f0..85cc0840b403 100644
--- a/tools/net/ynl/ynltool/Makefile
+++ b/tools/net/ynl/ynltool/Makefile
@@ -1,12 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
 include ../Makefile.deps
+include ../../../scripts/Makefile.include
 
 INSTALL	?= install
 prefix  ?= /usr
 
-CC := gcc
-CFLAGS := -Wall -Wextra -Werror -O2
+CFLAGS += -Wall -Wextra -Werror -O2
 ifeq ("$(DEBUG)","1")
   CFLAGS += -g -fsanitize=address -fsanitize=leak -static-libasan
 endif
-- 
2.55.0

Re: [PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools

[Matthieu Baerts]

On 03/09/2026 17:55, Maxime Chevallier (Netdev Foundation) wrote:
> The ynl tool and libraries may be built standalone or through the
> drivers/net/hw selftest machinery. This may target a different arch, so
> we need to account for the cross-compiling options such as CROSS_COMPILE
> or the LLVM-specific variables.
> 
> Let's include the tools/scripts/Makefile.include that deals with the
> CC/AR resolution.
> 
> Fixup the ynltool CFLAGS handling to use +=, so that we don't override
> the ones set in Makefile.include

Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>

Re: [PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 2 · Low: 1

- [Medium] Incomplete LLVM cross-compilation support: the commit claims
  to "account for the cross-compiling options such as CROSS_COMPILE or…
- [Medium] Include ordering bug in tools/net/ynl/Makefile: `include
  ../../scripts/Makefile.include` is added on line 4, i.e. *after*…
- [Low] Verbosity-control mismatch in tools/net/ynl/ynltool/Makefile: the
  patch adds `include ../../../scripts/Makefile.include` (line 4), which…

--

tools: ynl: Allow cross-compiling ynl and associated tools

The ynl Makefiles stop hardcoding CC=gcc and instead include
tools/scripts/Makefile.include so that CC/AR are resolved from
CROSS_COMPILE and the LLVM variables, and the ynltool CFLAGS assignment is
switched from := to += so it no longer clobbers the flags coming from
Makefile.include.

> diff --git a/tools/net/ynl/Makefile b/tools/net/ynl/Makefile
> index 3cefe4ed96cb..8bf72c063e86 100644
> --- a/tools/net/ynl/Makefile
> +++ b/tools/net/ynl/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  include ../../scripts/Makefile.arch
> +include ../../scripts/Makefile.include
>  
>  INSTALL	?= install
>  prefix  ?= /usr

[Severity: Medium]
Should the new include come before Makefile.arch rather than after it?

Makefile.arch probes the compiler with a simply-expanded assignment, so
${CC} and ${CFLAGS} are expanded at include time:

tools/scripts/Makefile.arch:
  LP64 := $(shell if command -v $(firstword ${CC}) >/dev/null 2>&1; then echo __LP64__ | ${CC} ${CFLAGS} -E -x c -; fi | tail -n 1)

At that point CC is still make's builtin cc and CFLAGS is empty, because
the allow-override of CC from CROSS_COMPILE and the CFLAGS += $(CLANG_CROSS_FLAGS)
in Makefile.include only run on the following line.

LP64 then feeds libdir_relative and libdir in this same Makefile:

  ifeq ($(LP64), 1)
    libdir_relative = lib64
  else
    libdir_relative = lib
  endif
  libdir  ?= $(prefix)/$(libdir_relative)

and libdir is used by the install target:

  @$(INSTALL) -d $(DESTDIR)$(libdir)
  @$(INSTALL) -m 0644 libynl.a $(DESTDIR)$(libdir)/libynl.a

So does make CROSS_COMPILE=arm-linux-gnueabihf- install on an x86_64 host
end up installing the 32-bit libynl.a under $(prefix)/lib64, with the
reverse happening on a 32-bit host cross-building for aarch64?

Other in-tree users of the same LP64/libdir_relative pattern include
Makefile.include first, for example tools/lib/perf/Makefile:

  include $(srctree)/tools/scripts/Makefile.include
  include $(srctree)/tools/scripts/Makefile.arch

Would simply swapping the two includes here be enough?

> diff --git a/tools/net/ynl/generated/Makefile b/tools/net/ynl/generated/Makefile
> index ea4128f612d6..5a186349b5a8 100644
> --- a/tools/net/ynl/generated/Makefile
> +++ b/tools/net/ynl/generated/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -CC=gcc
> +include ../../../scripts/Makefile.include
> +
>  CFLAGS += -std=gnu11 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow \
>  	-I../lib/ -idirafter $(UAPI_PATH)
>  ifeq ("$(DEBUG)","1")
> diff --git a/tools/net/ynl/lib/Makefile b/tools/net/ynl/lib/Makefile
> index 9b98c0599600..7b3eae89982f 100644
> --- a/tools/net/ynl/lib/Makefile
> +++ b/tools/net/ynl/lib/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -CC=gcc
> +include ../../../scripts/Makefile.include
> +
>  CFLAGS += -std=gnu11 -O2 -W -Wall -Wextra -Wno-unused-parameter -Wshadow
>  ifeq ("$(DEBUG)","1")
>    CFLAGS += -g -fsanitize=address -fsanitize=leak -static-libasan
> @@ -8,7 +9,6 @@ endif

[Severity: Medium]
The commit message says the change accounts for "the cross-compiling options
such as CROSS_COMPILE or the LLVM-specific variables". Does this also cover
the documented LLVM form described in Documentation/kbuild/llvm.rst, that is
make LLVM=1 ARCH=<arch> with no CROSS_COMPILE?

In tools/scripts/Makefile.include, the target triple is only appended inside
the CROSS_COMPILE branch:

  else ifneq ($(CROSS_COMPILE),)
  ifeq ($(CLANG_CROSS_FLAGS),)
  CLANG_TARGET := $(notdir $(CROSS_COMPILE:%-=%))
  ...
  CFLAGS += $(CLANG_CROSS_FLAGS)

With LLVM=1 and an empty CROSS_COMPILE, CC resolves to plain clang with no
--target, so lib/ynl.o and generated/*-user.o would be built for the host.

For the selftests path, tools/testing/selftests/lib.mk computes a
target-aware compiler from ARCH:

  CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as

but tools/testing/selftests/net/ynl.mk only forwards GENS and RSTS to the
sub-make:

  $(Q)$(MAKE) -C $(top_srcdir)/tools/net/ynl \
  	GENS="$(YNL_GENS)" RSTS="" libynl.a

Since ynl.mk forces the YNL_GEN_FILES targets (ncdevmem, toeplitz in
tools/testing/selftests/drivers/net/hw/Makefile) to link $(OUTPUT)/libynl.a,
does make LLVM=1 ARCH=arm64 -C tools/testing/selftests/drivers/net/hw fail at
link time with host objects in libynl.a against aarch64 objects?

If that configuration is out of scope for now, could the commit message say
so? The later patch "selftests: drv-net: Use cross-compilation environment
for the io_uring check" states the limitation explicitly ("this doesn't cover
the LLVM cross-compiling case though"), while this one reads as if the LLVM
case is handled.

[ ... ]

> diff --git a/tools/net/ynl/ynltool/Makefile b/tools/net/ynl/ynltool/Makefile
> index 48b0f32050f0..85cc0840b403 100644
> --- a/tools/net/ynl/ynltool/Makefile
> +++ b/tools/net/ynl/ynltool/Makefile
> @@ -1,12 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
>  include ../Makefile.deps
> +include ../../../scripts/Makefile.include
>  
>  INSTALL	?= install
>  prefix  ?= /usr
>  
> -CC := gcc
> -CFLAGS := -Wall -Wextra -Werror -O2
> +CFLAGS += -Wall -Wextra -Werror -O2
>  ifeq ("$(DEBUG)","1")
>    CFLAGS += -g -fsanitize=address -fsanitize=leak -static-libasan
>  endif

[Severity: Low]
This isn't a bug, but now that Makefile.include is pulled in here, the
existing Q assignment later in this same file disagrees with it:

tools/scripts/Makefile.include:
  ifeq ($(V),1)
    quiet =
    Q =
  else
    quiet = quiet_
    Q = @
  endif
  ...
  export quiet Q

tools/net/ynl/ynltool/Makefile, after the include:
  Q = @

  $(YNLTOOL): ../libynl.a $(OBJS)
  	$(Q)echo -e "\tLINK $@"
  	$(Q)$(CC) $(CFLAGS) -o $@ $(OBJS) ../libynl.a -lm

Since the local assignment comes after the include, does make V=1 -C
tools/net/ynl/ynltool still hide the CC and LINK command lines, which is
what one would want to look at when debugging a cross build? The same
overridden Q is also exported into the $(MAKE) -C ../ recursion for
../libynl.a. Could the local Q = @ line be dropped now?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903155524.2241065-1-maxime.chevallier%40bootlin.com

Re: [PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools

[Maxime Chevallier]

Hi,

On 9/6/26 17:00, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider:
> 
> Critical: 0 · High: 0 · Medium: 2 · Low: 1

[...]

> [Severity: Medium]
> Should the new include come before Makefile.arch rather than after it?

This looks like a legit point

[...]

> [Severity: Medium]
> The commit message says the change accounts for "the cross-compiling options
> such as CROSS_COMPILE or the LLVM-specific variables". Does this also cover
> the documented LLVM form described in Documentation/kbuild/llvm.rst, that is
> make LLVM=1 ARCH=<arch> with no CROSS_COMPILE?

I'll update the commit log to document the limitation

[...]

> [Severity: Low]
> This isn't a bug, but now that Makefile.include is pulled in here, the
> existing Q assignment later in this same file disagrees with it:

Also legit as well.

So, I'll swap the Makefile.arch and Makefile.include inclusions, document in
the commit log that we don't deal with LLVM + no CROSS_COMPILE, and drop the

Q = @

line in ynltool/Makefile.

Matthieu, are you OK with me keeping your review tag with the above changes,
or do I drop it and resend for you to re-review ?

Maxime

Re: [PATCH net-next v2 1/2] tools: ynl: Allow cross-compiling ynl and associated tools

[Matthieu Baerts]

Hi Maxime,

On 07/09/2026 10:22, Maxime Chevallier wrote:
> Hi,
> 
> On 9/6/26 17:00, netdev-bot+sashiko@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 3 potential
>> issue(s) to consider:
>>
>> Critical: 0 · High: 0 · Medium: 2 · Low: 1
> 
> [...]
> 
>> [Severity: Medium]
>> Should the new include come before Makefile.arch rather than after it?
> 
> This looks like a legit point
> 
> [...]
> 
>> [Severity: Medium]
>> The commit message says the change accounts for "the cross-compiling options
>> such as CROSS_COMPILE or the LLVM-specific variables". Does this also cover
>> the documented LLVM form described in Documentation/kbuild/llvm.rst, that is
>> make LLVM=1 ARCH=<arch> with no CROSS_COMPILE?
> 
> I'll update the commit log to document the limitation
> 
> [...]
> 
>> [Severity: Low]
>> This isn't a bug, but now that Makefile.include is pulled in here, the
>> existing Q assignment later in this same file disagrees with it:
> 
> Also legit as well.
> 
> So, I'll swap the Makefile.arch and Makefile.include inclusions, document in
> the commit log that we don't deal with LLVM + no CROSS_COMPILE, and drop the
> 
> Q = @
> 
> line in ynltool/Makefile.
> 
> Matthieu, are you OK with me keeping your review tag with the above changes,
> or do I drop it and resend for you to re-review ?

Thank you for asking. I agree with the above changes, (and TBH, I didn't
check for such issues in my review :) ), so you can keep my RvB tag.

Cheers,
Matt

[PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[Maxime Chevallier (Netdev Foundation)]

To test for the presence of zerocopy support in the available liburing,
a small check program is compiled.

The CC value used for the io_uring library check defaults to the host
compiler, which will fail in cross-compiling environments.

Normally the CC for cross-compile is set in lib.mk, but this also
requires the test list to be set when we include it, and this check
needs to run first.

Note that this doesn't cover the LLVM cross-compiling case though.

Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
---
V2: Use an LLVM-aware construct for CC construction, from Mattieu

 tools/testing/selftests/drivers/net/hw/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
index 6105be8e590f..f9458dc6c150 100644
--- a/tools/testing/selftests/drivers/net/hw/Makefile
+++ b/tools/testing/selftests/drivers/net/hw/Makefile
@@ -1,5 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0+ OR MIT
 
+# Set CC for the io_uring check
+ifeq ($(LLVM)$(CC),cc)
+CC := $(CROSS_COMPILE)gcc
+endif
+
 # Check if io_uring supports zero-copy receive
 HAS_IOURING_ZCRX := $(shell \
 	echo -e '#include <liburing.h>\n' \
-- 
2.55.0

Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[Matthieu Baerts]

Hi Maxime,

On 03/09/2026 17:55, Maxime Chevallier (Netdev Foundation) wrote:
> To test for the presence of zerocopy support in the available liburing,
> a small check program is compiled.
> 
> The CC value used for the io_uring library check defaults to the host
> compiler, which will fail in cross-compiling environments.
> 
> Normally the CC for cross-compile is set in lib.mk, but this also
> requires the test list to be set when we include it, and this check
> needs to run first.
> 
> Note that this doesn't cover the LLVM cross-compiling case though.

Thank you for the new version!

Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>

"(Netdev Foundation)" is quite long, we should have a shorter version :P

Cheers,
Matt

Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 1

- [Medium] Incomplete fix: the capability probe still uses a different
  compiler than the one lib.mk installs to build `iou-zcrx`, in two…
- [Low] Missing `Fixes:` tag.

--

selftests: drv-net: Use cross-compilation environment for the io_uring check

This patch sets CC to $(CROSS_COMPILE)gcc at the top of
tools/testing/selftests/drivers/net/hw/Makefile so that the liburing
zero-copy capability probe (HAS_IOURING_ZCRX) is compiled with the
cross compiler instead of make's built-in default. The override is
guarded by ifeq ($(LLVM)$(CC),cc).

[Severity: Low]

Should this carry a Fixes: tag?  git blame on the baseline attributes the
whole probe block, including the ifeq ($(HAS_IOURING_ZCRX),y) gating, to
f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C
code").  Since no CC is set before the probe in this Makefile, in
tools/testing/selftests/Makefile, or in lib.mk, that commit is where the
probe started evaluating with the built-in CC=cc in cross builds:

  Fixes: f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C code")

On the changelog wording:

> The CC value used for the io_uring library check defaults to the host
> compiler, which will fail in cross-compiling environments.

Does the check actually fail?  The compile of the probe program succeeds or
fails against the host's liburing, so the result simply describes the host
rather than the target.  The failure comes later, when iou-zcrx is
cross-built and linked with -luring, or the test is silently dropped.
Would it be more accurate to describe it that way?

> diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
> index 6105be8e590f..f9458dc6c150 100644
> --- a/tools/testing/selftests/drivers/net/hw/Makefile
> +++ b/tools/testing/selftests/drivers/net/hw/Makefile
> @@ -1,5 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0+ OR MIT
>  
> +# Set CC for the io_uring check
> +ifeq ($(LLVM)$(CC),cc)
> +CC := $(CROSS_COMPILE)gcc
> +endif
> +

[Severity: Medium]

Can the probe and the actual build of iou-zcrx still end up on different
compilers after this change?  The guard only matches when LLVM is empty and
CC still holds the built-in value cc.

Two cases seem to slip through:

  make LLVM=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- ...

  $(LLVM)$(CC) expands to "1cc", the ifeq is false, so HAS_IOURING_ZCRX is
  probed with the host cc while lib.mk later sets:

    CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as

CC arriving from the environment with any value other than cc.  The
top-level kernel Makefile has:

    export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG

so kbuild-driven builds such as make kselftest always have CC in the
environment (plain clang with no --target under LLVM=1).  The ifeq is
false, the probe uses that compiler, but lib.mk's plain := assignment
overrides an environment CC for the real build:

    CC := $(CROSS_COMPILE)gcc

In both cases, a host liburing that has io_uring_register_ifq sets
HAS_IOURING_ZCRX=y, which adds iou-zcrx to COND_GEN_FILES and enables:

    $(OUTPUT)/iou-zcrx: LDLIBS += -luring

Does the subsequent cross compile then abort on liburing.h or -luring
instead of taking the graceful path?

    $(warning excluding iouring tests, liburing not installed or too old)

The inverse case, where the target sysroot has liburing but the host does
not, would silently drop a supported test.

Since the probe is expanded well before include ../../../lib.mk, would it
be possible to mirror lib.mk's own CC derivation here, or to move the probe
after lib.mk is included, so the gate always matches the compiler that
builds iou-zcrx?

>  # Check if io_uring supports zero-copy receive
>  HAS_IOURING_ZCRX := $(shell \
>  	echo -e '#include <liburing.h>\n' \

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903155524.2241065-1-maxime.chevallier%40bootlin.com

Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[Maxime Chevallier]

Hi,

On 9/6/26 17:00, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider:
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 1
> 
> - [Medium] Incomplete fix: the capability probe still uses a different
>   compiler than the one lib.mk installs to build `iou-zcrx`, in two…
> - [Low] Missing `Fixes:` tag.
> 
> --
> 
> selftests: drv-net: Use cross-compilation environment for the io_uring check
> 
> This patch sets CC to $(CROSS_COMPILE)gcc at the top of
> tools/testing/selftests/drivers/net/hw/Makefile so that the liburing
> zero-copy capability probe (HAS_IOURING_ZCRX) is compiled with the
> cross compiler instead of make's built-in default. The override is
> guarded by ifeq ($(LLVM)$(CC),cc).
> 
> [Severity: Low]
> 
> Should this carry a Fixes: tag?  git blame on the baseline attributes the
> whole probe block, including the ifeq ($(HAS_IOURING_ZCRX),y) gating, to
> f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C
> code").  Since no CC is set before the probe in this Makefile, in
> tools/testing/selftests/Makefile, or in lib.mk, that commit is where the
> probe started evaluating with the built-in CC=cc in cross builds:
> 
>   Fixes: f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C code")

Yeah but OTHO this never worked, and apparently was never tested before.

> 
> On the changelog wording:
> 
>> The CC value used for the io_uring library check defaults to the host
>> compiler, which will fail in cross-compiling environments.

I'll reword yeah...

[...]

> 
> Since the probe is expanded well before include ../../../lib.mk, would it
> be possible to mirror lib.mk's own CC derivation here, or to move the probe
> after lib.mk is included, so the gate always matches the compiler that
> builds iou-zcrx?

Well this is what I wanted to avoid :(

Let me reword the commit log for V2, Matthieu if that's OK I'll also keep your
R-b, as I'll leave the code as-is unless someone has any objection ?

Maxime

Re: [PATCH net-next v2 2/2] selftests: drv-net: Use cross-compilation environment for the io_uring check

[Matthieu Baerts]

On 07/09/2026 15:51, Maxime Chevallier wrote:
> Hi,
> 
> On 9/6/26 17:00, netdev-bot+sashiko@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 2 potential
>> issue(s) to consider:
>>
>> Critical: 0 · High: 0 · Medium: 1 · Low: 1
>>
>> - [Medium] Incomplete fix: the capability probe still uses a different
>>   compiler than the one lib.mk installs to build `iou-zcrx`, in two…
>> - [Low] Missing `Fixes:` tag.
>>
>> --
>>
>> selftests: drv-net: Use cross-compilation environment for the io_uring check
>>
>> This patch sets CC to $(CROSS_COMPILE)gcc at the top of
>> tools/testing/selftests/drivers/net/hw/Makefile so that the liburing
>> zero-copy capability probe (HAS_IOURING_ZCRX) is compiled with the
>> cross compiler instead of make's built-in default. The override is
>> guarded by ifeq ($(LLVM)$(CC),cc).
>>
>> [Severity: Low]
>>
>> Should this carry a Fixes: tag?  git blame on the baseline attributes the
>> whole probe block, including the ifeq ($(HAS_IOURING_ZCRX),y) gating, to
>> f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C
>> code").  Since no CC is set before the probe in this Makefile, in
>> tools/testing/selftests/Makefile, or in lib.mk, that commit is where the
>> probe started evaluating with the built-in CC=cc in cross builds:
>>
>>   Fixes: f81171fecd0c3 ("selftests: hw-net: auto-disable building the iouring C code")
> 
> Yeah but OTHO this never worked, and apparently was never tested before.
> 
>>
>> On the changelog wording:
>>
>>> The CC value used for the io_uring library check defaults to the host
>>> compiler, which will fail in cross-compiling environments.
> 
> I'll reword yeah...
> 
> [...]
> 
>>
>> Since the probe is expanded well before include ../../../lib.mk, would it
>> be possible to mirror lib.mk's own CC derivation here, or to move the probe
>> after lib.mk is included, so the gate always matches the compiler that
>> builds iou-zcrx?
> 
> Well this is what I wanted to avoid :(
> 
> Let me reword the commit log for V2, Matthieu if that's OK I'll also keep your
> R-b, as I'll leave the code as-is unless someone has any objection ?

Fine by me to document this "limitation" but keep it as is: I think the
proposed "workaround" is enough for this case.

Cheers,
Matt

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Andrew Lunn]

On Thu, Sep 03, 2026 at 05:55:21PM +0200, Maxime Chevallier (Netdev Foundation) wrote:
> Hi everyone, here's V2 for cross-compilation improvements for the
> drivers/net/hw selftests.
> 
> Patch 1 fixes YNL cross compilation, while patch 2 deals with the
> iou_zcrx check.
> 
> Jakub asked :
> 
>   I assume you don't actually have luring for your cross- env? Could we
>   keep it simple and just declare luring as unavailable when cross
>   compiling? Because the probing compilation rule is probably missing 
>   more flags to make cross compilation work.
> 
>   Ignore if selftests using luring do actually work for you after this
>   patch..
> 
> Turns out I did have liburing in the CC env (generated from Buildroot,
> which supports liburing), and the cross-compiled liburing check worked
> as expected :)

Nice. Did you give the liburing tests a quick smoke test?

I get the feeling not many Embedded people run the self tests, if
basic things like cross compilation does not work, and native 32bit
builds spits out 1000s of warnings.

       Andrew

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Matthieu Baerts]

Hi Andrew,

On 03/09/2026 18:51, Andrew Lunn wrote:
> I get the feeling not many Embedded people run the self tests, if
> basic things like cross compilation does not work, and native 32bit
> builds spits out 1000s of warnings.

Maybe they do, but they are possibly a few (LTS) kernel versions behind :)

Cheers,
Matt

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Maxime Chevallier]

On 9/3/26 18:51, Andrew Lunn wrote:

> Nice. Did you give the liburing tests a quick smoke test?

I had to bump liburing on my BR setup, I managed to get it to run, but
it wasn't easy :/

I've started an effort to run the kselftests on my fleet of random devices,
trying various ways of interconnecting them with one another. This will be
needed for the ethtool tests.

I'm generating my rootfs with buildroot on all my boards, so I'm slowly getting
a list of options to enable for proper kselftest runs.

Focusing only on drivers/net/hw, all the kselftests that tests the local device
have no trouble running once you get the proper list dependencies installed.

(one example, some tests will grep through include/linux/ethtool.h, so you need
kernel headers on the rootfs)

I've already found some drivers bugs here and there with that, for example mvpp2
fails the RSS kselftests (wonder who wrote that...)

But then there's the kselftests that require a peer, and here it's another story.
Some tests, when using the SSH remote type, will scp a small binary on the peer
and use that binary for testing (sending specially crafted frames, etc.)

Just in the drivers/net/hw tests, we have :

drivers/net/hw/csum.py
drivers/net/hw/devmem_lib.py
drivers/net/hw/gro_hw.py
drivers/net/hw/iou-zcrx.py
drivers/net/hw/nk_qlease.py

Thing is, what I have is a mixed bag of arm, aarch64, a few riscv, x86 and even
ppc32 in there, so as you can guess, scp'ing an arm binary on a riscv peer doesn't
work as one expects... took me a while to figure this out :(

My setup is quite extreme but even for day to day development, I suspect most devs are
directly connecting their embedded board to their x86 host for testing.

We could expand the remote_ssh logic to probe the peer, and raise a skip if it's
a different arch than the dut. Or better, have the DUT check if the peer doesn't
already have the tool in question, i.e. the kselftest "package" is also installed
there.

> 
> I get the feeling not many Embedded people run the self tests, if
> basic things like cross compilation does not work, and native 32bit
> builds spits out 1000s of warnings.

Indeed... my idea for stmmac is to grab as many random stmmac boards as I can to get
a good sample of glue drivers + PHYs, and run the kselftest on them (hopefully one
day feeding that into NIPA).

I can already tell the simple kselftests run well when cross-compiled on arm, aarch64
and riscv but the interop issue needs resolving. Then it's a matter of adding a lot more
tests. Hopefully this will give enough experience on what's to solve so that
everyone else can do it as well...

Maxime

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Andrew Lunn]

> But then there's the kselftests that require a peer, and here it's another story.
> Some tests, when using the SSH remote type, will scp a small binary on the peer
> and use that binary for testing (sending specially crafted frames, etc.)
> 
> Just in the drivers/net/hw tests, we have :
> 
> drivers/net/hw/csum.py
> drivers/net/hw/devmem_lib.py
> drivers/net/hw/gro_hw.py
> drivers/net/hw/iou-zcrx.py
> drivers/net/hw/nk_qlease.py

But none of these are binary, so long as you run the .py file, not a
pyc file.

iou-zcrx.c ncdevmem.c nk_forward.bpf.c nk_primary_rx_redirect.bpf.c
toeplitz.c would be a problem.

> We could expand the remote_ssh logic to probe the peer, and raise a skip if it's
> a different arch than the dut. Or better, have the DUT check if the peer doesn't
> already have the tool in question, i.e. the kselftest "package" is also installed
> there.

https://github.com/torvalds/linux/blob/master/Documentation/dev-tools/kselftest.rst#install-selftests

does talk about installing the self tests. Maybe somewhere in
/usr/local/libexec or /usr/local/bin. 

	Andrew

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Maxime Chevallier]

On 9/3/26 23:59, Andrew Lunn wrote:
>> But then there's the kselftests that require a peer, and here it's another story.
>> Some tests, when using the SSH remote type, will scp a small binary on the peer
>> and use that binary for testing (sending specially crafted frames, etc.)
>>
>> Just in the drivers/net/hw tests, we have :
>>
>> drivers/net/hw/csum.py
>> drivers/net/hw/devmem_lib.py
>> drivers/net/hw/gro_hw.py
>> drivers/net/hw/iou-zcrx.py
>> drivers/net/hw/nk_qlease.py
> 
> But none of these are binary, so long as you run the .py file, not a
> pyc file.
> 
> iou-zcrx.c ncdevmem.c nk_forward.bpf.c nk_primary_rx_redirect.bpf.c
> toeplitz.c would be a problem.

What I meant is that all the .py files above are selftests that are copying
actual biniares (generated from the c files you mention)

e.g.

drivers/net/hw/csum.py sends the binary generated from net/lib/csum.c to the peer


> 
>> We could expand the remote_ssh logic to probe the peer, and raise a skip if it's
>> a different arch than the dut. Or better, have the DUT check if the peer doesn't
>> already have the tool in question, i.e. the kselftest "package" is also installed
>> there.
> 
> https://github.com/torvalds/linux/blob/master/Documentation/dev-tools/kselftest.rst#install-selftests
> 
> does talk about installing the self tests. Maybe somewhere in
> /usr/local/libexec or /usr/local/bin. 

Yep that's what I meant, this is what buildroot uses to populate the rootfs on the target

Maxime

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Jakub Kicinski]

On Thu, 3 Sep 2026 23:44:51 +0200 Maxime Chevallier wrote:
> We could expand the remote_ssh logic to probe the peer, and raise a skip if it's
> a different arch than the dut. Or better, have the DUT check if the peer doesn't
> already have the tool in question, i.e. the kselftest "package" is also installed
> there.

FTR the remote* API is supposed to make it easy to drop-in
your own implementation (as in you should be able to copy an extra file
in the right place and use it without patching anything). 
You can probably do some extra binary jugging / probing in your own
class. I was trying to avoid having to carry bespoke handlers directly
in the kernel tree.

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Andrew Lunn]

> Tested on an aarch64 target, built on x86_64.

Probably a question for Jakub or Matthieu.

As part of the CI system which is feeding into patchworks, I don't
think we build the selftests? Do we have the CPU resources to build
them?

We currently do x86 64 and 32 bit builds. Do we have the CPU resources
to do an arm64 cross build?

I assume a cross build the self tests needs something like buildroot
to be sensible? Or Debians multi-arch stuff where you can install .deb
packages for libraries for other architectures? So maybe that is going
too far?

   Andrew

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Matthieu Baerts]

Hi Andrew,

On 03/09/2026 19:11, Andrew Lunn wrote:
>> Tested on an aarch64 target, built on x86_64.
> 
> Probably a question for Jakub or Matthieu.
> 
> As part of the CI system which is feeding into patchworks, I don't
> think we build the selftests? Do we have the CPU resources to build
> them?

We do: the "build_tools" script [1] checks that. And they are also built
before launching the selftests.

> We currently do x86 64 and 32 bit builds. Do we have the CPU resources
> to do an arm64 cross build?

I think we do, but I don't know if we need to (see below)

> I assume a cross build the self tests needs something like buildroot
> to be sensible? Or Debians multi-arch stuff where you can install .deb
> packages for libraries for other architectures? So maybe that is going
> too far?

From what I understood, the goal is to execute the selftests on embedded
systems as well, which will require building new image including the
kernel and the drivers/net selftests. Do we need to build the whole
kernel for arm64? :)

Cheers,
Matt

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Andrew Lunn]

On Thu, Sep 03, 2026 at 07:25:22PM +0200, Matthieu Baerts wrote:
> Hi Andrew,
> 
> On 03/09/2026 19:11, Andrew Lunn wrote:
> >> Tested on an aarch64 target, built on x86_64.
> > 
> > Probably a question for Jakub or Matthieu.
> > 
> > As part of the CI system which is feeding into patchworks, I don't
> > think we build the selftests? Do we have the CPU resources to build
> > them?
> 
> We do: the "build_tools" script [1] checks that. And they are also built
> before launching the selftests.
> 
> > We currently do x86 64 and 32 bit builds. Do we have the CPU resources
> > to do an arm64 cross build?
> 
> I think we do, but I don't know if we need to (see below)
> 
> > I assume a cross build the self tests needs something like buildroot
> > to be sensible? Or Debians multi-arch stuff where you can install .deb
> > packages for libraries for other architectures? So maybe that is going
> > too far?
> 
> >From what I understood, the goal is to execute the selftests on embedded
> systems as well, which will require building new image including the
> kernel and the drivers/net selftests. Do we need to build the whole
> kernel for arm64? :)

I see a few different goals.

Picking a patch at random:

https://patchwork.kernel.org/project/netdevbpf/patch/20260903-netcons_ipv6-v4-2-bdd183c844d3@gmail.com/

We see 32bit, allmodconfig, clang, and clang_rust. These are all
native builds, which given are servers are AMD64, these are AMD64
builds.

However, many of the network drivers are used on ARM platforms. Most
probably do compile on AMD64, but i expect there are a few which
don't. So we could do an ARM64 cross compile, to make sure the patches
are clean on ARM64 as well as AMD64.

We are encouraging developers to write self tests. Ideally we want
self test patches to be held to the same standard as driver
patches. So if a patch touches the self tests, it would be good to
build the self tests in order to show the number of warnings & errors
has not gone up. I expect such a build will be native.

But if we have gone to the time/effort to cross compile the kernel,
can we also cross compile the self tests? Can we ensure with cross
compile self tests don't have more warnings/errors, because the self
test write has AMD64 blinkers on?

And sometime down the road, we would like to get ARM servers, with
NICs in them, to run the self tests on. At that point, we either need
to cross compile the kernel to run all the self tests, or we need
another build server which is ARM64, so it can do native ARM64 builds
of the kernel to run on the ARM64 runners.

     Andrew

Re: [PATCH net-next v2 0/2] selftests: drv-net: Allow cross-compiling the hardware tests

[Matthieu Baerts]

Hi Andrew,

On 03/09/2026 22:55, Andrew Lunn wrote:
> On Thu, Sep 03, 2026 at 07:25:22PM +0200, Matthieu Baerts wrote:
>> Hi Andrew,
>>
>> On 03/09/2026 19:11, Andrew Lunn wrote:
>>>> Tested on an aarch64 target, built on x86_64.
>>>
>>> Probably a question for Jakub or Matthieu.
>>>
>>> As part of the CI system which is feeding into patchworks, I don't
>>> think we build the selftests? Do we have the CPU resources to build
>>> them?
>>
>> We do: the "build_tools" script [1] checks that. And they are also built
>> before launching the selftests.
>>
>>> We currently do x86 64 and 32 bit builds. Do we have the CPU resources
>>> to do an arm64 cross build?
>>
>> I think we do, but I don't know if we need to (see below)
>>
>>> I assume a cross build the self tests needs something like buildroot
>>> to be sensible? Or Debians multi-arch stuff where you can install .deb
>>> packages for libraries for other architectures? So maybe that is going
>>> too far?
>>
>> >From what I understood, the goal is to execute the selftests on embedded
>> systems as well, which will require building new image including the
>> kernel and the drivers/net selftests. Do we need to build the whole
>> kernel for arm64? :)
> 
> I see a few different goals.
> 
> Picking a patch at random:
> 
> https://patchwork.kernel.org/project/netdevbpf/patch/20260903-netcons_ipv6-v4-2-bdd183c844d3@gmail.com/
> 
> We see 32bit, allmodconfig, clang, and clang_rust. These are all
> native builds, which given are servers are AMD64, these are AMD64
> builds.
> 
> However, many of the network drivers are used on ARM platforms. Most
> probably do compile on AMD64, but i expect there are a few which
> don't. So we could do an ARM64 cross compile, to make sure the patches
> are clean on ARM64 as well as AMD64.
> 
> We are encouraging developers to write self tests. Ideally we want
> self test patches to be held to the same standard as driver
> patches. So if a patch touches the self tests, it would be good to
> build the self tests in order to show the number of warnings & errors
> has not gone up. I expect such a build will be native.
> 
> But if we have gone to the time/effort to cross compile the kernel,
> can we also cross compile the self tests? Can we ensure with cross
> compile self tests don't have more warnings/errors, because the self
> test write has AMD64 blinkers on?
> 
> And sometime down the road, we would like to get ARM servers, with
> NICs in them, to run the self tests on. At that point, we either need
> to cross compile the kernel to run all the self tests, or we need
> another build server which is ARM64, so it can do native ARM64 builds
> of the kernel to run on the ARM64 runners.
I agree that the Netdev CI currently doesn't build anything for the
ARM64 target. But what I meant is that the goal of Maxime's work (if I
understood correctly) is to execute the net selftests (or just the
drv-net ones?) on embedded systems, with different targets. From your
reply, I guess you meant that it might not be enough to have a good
coverage.

I don't think I can properly judge if this is required or not. My
feeling is that it might not be worth it: I don't recall having seen
many fixes specific to other architectures, plus the Intel's bot is
still building the kernel for many architectures. What is currently
missing is compiling the net selftests for different arch. But if ARM64
is added, which other ones should be added too? Plus maybe adding this
would no longer be needed thanks to Maxime's work where selftests will
be built for many architectures and issues reported to NIPA's dashboard?

But I'm aware I have probably missed something, and ARM64 builds might
be worth it. Should we discuss that at the next Netdev bi-weekly call?

Cheers,
Matt