[Buildroot] [PATCH] support/testing: test_xen: add networking

[Julien Olivain]

Hi Vincent,

Thanks for the patch.

On 10/10/2025 09:29, Vincent Stehlé wrote:
> Enhance the Xen python tests to exercise networking:
> 
> - Add the networking support we need to the Linux kernel 
> configurations.
> - Add a virtual network interface to the Xen dom1 configurations.
> - Update the test in the following way:
>   * Start the emulator with restricted networking.
>   * Create a network bridge in dom0.
>   * Check that networking is functional in both domains by ping'ing the
>     gateway.
>   (Refer also to the diagram in the python script.)
> - While at it, bump Linux kernel to 6.17.1 and U-Boot to 2025.07.
>   We also need to adjust the DTB address in the Arm 32b U-Boot script 
> to
>   accommodate the new U-Boot version, which does not have enough free 
> space
>   around the control DTB anymore.
> 
> Signed-off-by: Vincent Stehlé <vincent.stehle at arm.com>

For some reason, the TestXenArmv7 runtime test is failing in the
reference Buildroot Docker image. I tested with the command:

     utils/docker-run support/testing/run-tests \
         -k -d dl -o output_folder \
         tests.package.test_xen

The file output_folder/TestXenArmv7-run.log ends with:

	[BRTEST# udhcpc -i eth0
	udhcpc: started, v1.37.0
	udhcpc: broadcasting discover
	udhcpc: broadcasting discover

Strangely, the TestXenAarch64 is passing in the Build Docker image.

I initially thought it was a timing issue, but I tested several times
and I consistently got the same result.

Both tests are passing on a Fedora 42 host with qemu 9.2.4.

The Buildroot Docker image has an "old" qemu 7.2.15. See the command:

     utils/docker-run qemu-system-arm --version

which output:

     QEMU emulator version 7.2.15 (Debian 1:7.2+dfsg-7+deb12u12)

I tested by adding in the test config:

     BR2_PACKAGE_HOST_QEMU=y
     BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y

in order to compile a more recent qemu 10.1.0. This seems to
solve or workaround the issue.

For the moment, I cannot tell if it's a network emulation bug in
the old qemu (which in that case the test needs to compile the newer
qemu), or if it's a timing issue in the test (i.e. the test
might need to wait a bit somewhere to let the bridge settle).

Could you have a look please and send an updated patch addressing
this issue, please?

Best regards,

Julien.