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

> 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

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

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

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

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

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

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.

> 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

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

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