[PATCH for 10.1 00/13] documentation updates and test tweaks

[PATCH for 10.1 00/13] documentation updates and test tweaks

[Alex Bennée]

I did a quick pass of some of the documentation bugs and tried to
clean-up the linux-user documentation some more.

I've also tackled the exploding number of TCG tests by rotating the
plugin run against test rather than having every combination. We now
have enough multiarch tests I'm fairly confident this gives good
enough coverage of the APIs. Some plugins have explicit test programs
they need to be run against and these are still added manually.

The following need review:

  tests/docker: handle host-arch selection for all-test-cross
  tests/docker: add --arch-only to qemu deps for all-test-cross
  tests/tcg: reduce the number of plugin tests combinations
  configure: expose PYTHON to test/tcg/config-host.mak
  tests/tcg: don't include multiarch tests if not supported
  tests/tcg: remove ADDITIONAL_PLUGINS_TESTS
  tests/tcg: skip libsyscall.so on softmmu tests
  tests/functional: add hypervisor test for aarch64
  docs/user: expand section on threading
  docs/user: slightly reword section on system calls
  docs/user: clean up headings
  docs/system: reword the TAP notes to remove tarball ref
  docs/user: clarify user-mode expects the same OS

Alex.

Alex Bennée (13):
  docs/user: clarify user-mode expects the same OS
  docs/system: reword the TAP notes to remove tarball ref
  docs/user: clean up headings
  docs/user: slightly reword section on system calls
  docs/user: expand section on threading
  tests/functional: add hypervisor test for aarch64
  tests/tcg: skip libsyscall.so on softmmu tests
  tests/tcg: remove ADDITIONAL_PLUGINS_TESTS
  tests/tcg: don't include multiarch tests if not supported
  configure: expose PYTHON to test/tcg/config-host.mak
  tests/tcg: reduce the number of plugin tests combinations
  tests/docker: add --arch-only to qemu deps for all-test-cross
  tests/docker: handle host-arch selection for all-test-cross

 docs/system/devices/net.rst                   | 16 ++--
 docs/user/index.rst                           |  5 +-
 docs/user/main.rst                            | 59 ++++++++-----
 configure                                     |  1 +
 .../dockerfiles/debian-all-test-cross.docker  | 33 ++++----
 tests/functional/meson.build                  |  1 +
 tests/functional/test_aarch64_kvm.py          | 83 +++++++++++++++++++
 tests/tcg/Makefile.target                     | 36 ++++++--
 tests/tcg/multiarch/Makefile.target           |  8 +-
 .../multiarch/system/Makefile.softmmu-target  | 16 +++-
 10 files changed, 201 insertions(+), 57 deletions(-)
 create mode 100755 tests/functional/test_aarch64_kvm.py

-- 
2.47.2

[PATCH for 10.1 01/13] docs/user: clarify user-mode expects the same OS

[Alex Bennée]

While we somewhat cover this later when we talk about supported
operating systems make it clear in the front matter.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/user/index.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/user/index.rst b/docs/user/index.rst
index 782d27cda27..2307580cb97 100644
--- a/docs/user/index.rst
+++ b/docs/user/index.rst
@@ -5,8 +5,9 @@ User Mode Emulation
 -------------------
 
 This section of the manual is the overall guide for users using QEMU
-for user-mode emulation.  In this mode, QEMU can launch
-processes compiled for one CPU on another CPU.
+for user-mode emulation. In this mode, QEMU can launch programs
+compiled for one CPU architecture on the same Operating System (OS)
+but running on a different CPU architecture.
 
 .. toctree::
    :maxdepth: 2
-- 
2.47.2

Re: [PATCH for 10.1 01/13] docs/user: clarify user-mode expects the same OS

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 1:59 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> While we somewhat cover this later when we talk about supported
> operating systems make it clear in the front matter.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/user/index.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/docs/user/index.rst b/docs/user/index.rst
> index 782d27cda27..2307580cb97 100644
> --- a/docs/user/index.rst
> +++ b/docs/user/index.rst
> @@ -5,8 +5,9 @@ User Mode Emulation
>  -------------------
>
>  This section of the manual is the overall guide for users using QEMU
> -for user-mode emulation.  In this mode, QEMU can launch
> -processes compiled for one CPU on another CPU.
> +for user-mode emulation. In this mode, QEMU can launch programs
> +compiled for one CPU architecture on the same Operating System (OS)
> +but running on a different CPU architecture.
>
>  .. toctree::
>     :maxdepth: 2
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 02/13] docs/system: reword the TAP notes to remove tarball ref

[Alex Bennée]

We don't ship the tarball and users should generally look to the
distribution specific packaging.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/560
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/system/devices/net.rst | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/docs/system/devices/net.rst b/docs/system/devices/net.rst
index 4d787c3aeb0..7d76fe88c45 100644
--- a/docs/system/devices/net.rst
+++ b/docs/system/devices/net.rst
@@ -21,11 +21,17 @@ configure it as if it was a real ethernet card.
 Linux host
 ^^^^^^^^^^
 
-As an example, you can download the ``linux-test-xxx.tar.gz`` archive
-and copy the script ``qemu-ifup`` in ``/etc`` and configure properly
-``sudo`` so that the command ``ifconfig`` contained in ``qemu-ifup`` can
-be executed as root. You must verify that your host kernel supports the
-TAP network interfaces: the device ``/dev/net/tun`` must be present.
+A distribution will generally provide specific helper scripts when it
+packages QEMU. By default these are found at ``/etc/qemu-ifup`` and
+``/etc/qemu-ifdown`` and are called appropriately when QEMU wants to
+change the network state.
+
+If QEMU is being run as a non-privileged user you may need properly
+configure ``sudo`` so that network commands in the scripts can be
+executed as root.
+
+You must verify that your host kernel supports the TAP network
+interfaces: the device ``/dev/net/tun`` must be present.
 
 See :ref:`sec_005finvocation` to have examples of command
 lines using the TAP network interfaces.
-- 
2.47.2

Re: [PATCH for 10.1 02/13] docs/system: reword the TAP notes to remove tarball ref

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:02 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> We don't ship the tarball and users should generally look to the
> distribution specific packaging.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/560
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/system/devices/net.rst | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/docs/system/devices/net.rst b/docs/system/devices/net.rst
> index 4d787c3aeb0..7d76fe88c45 100644
> --- a/docs/system/devices/net.rst
> +++ b/docs/system/devices/net.rst
> @@ -21,11 +21,17 @@ configure it as if it was a real ethernet card.
>  Linux host
>  ^^^^^^^^^^
>
> -As an example, you can download the ``linux-test-xxx.tar.gz`` archive
> -and copy the script ``qemu-ifup`` in ``/etc`` and configure properly
> -``sudo`` so that the command ``ifconfig`` contained in ``qemu-ifup`` can
> -be executed as root. You must verify that your host kernel supports the
> -TAP network interfaces: the device ``/dev/net/tun`` must be present.
> +A distribution will generally provide specific helper scripts when it
> +packages QEMU. By default these are found at ``/etc/qemu-ifup`` and
> +``/etc/qemu-ifdown`` and are called appropriately when QEMU wants to
> +change the network state.
> +
> +If QEMU is being run as a non-privileged user you may need properly
> +configure ``sudo`` so that network commands in the scripts can be
> +executed as root.
> +
> +You must verify that your host kernel supports the TAP network
> +interfaces: the device ``/dev/net/tun`` must be present.
>
>  See :ref:`sec_005finvocation` to have examples of command
>  lines using the TAP network interfaces.
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 03/13] docs/user: clean up headings

[Alex Bennée]

This was a slightly duff format for rst, make it use proper headings.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/user/main.rst | 50 ++++++++++++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/docs/user/main.rst b/docs/user/main.rst
index 9a1c60448c5..b8ff203c212 100644
--- a/docs/user/main.rst
+++ b/docs/user/main.rst
@@ -17,28 +17,34 @@ Features
 
 QEMU user space emulation has the following notable features:
 
-**System call translation:**
-   QEMU includes a generic system call translator. This means that the
-   parameters of the system calls can be converted to fix endianness and
-   32/64-bit mismatches between hosts and targets. IOCTLs can be
-   converted too.
-
-**POSIX signal handling:**
-   QEMU can redirect to the running program all signals coming from the
-   host (such as ``SIGALRM``), as well as synthesize signals from
-   virtual CPU exceptions (for example ``SIGFPE`` when the program
-   executes a division by zero).
-
-   QEMU relies on the host kernel to emulate most signal system calls,
-   for example to emulate the signal mask. On Linux, QEMU supports both
-   normal and real-time signals.
-
-**Threading:**
-   On Linux, QEMU can emulate the ``clone`` syscall and create a real
-   host thread (with a separate virtual CPU) for each emulated thread.
-   Note that not all targets currently emulate atomic operations
-   correctly. x86 and Arm use a global lock in order to preserve their
-   semantics.
+System call translation
+~~~~~~~~~~~~~~~~~~~~~~~
+
+QEMU includes a generic system call translator. This means that the
+parameters of the system calls can be converted to fix endianness
+and 32/64-bit mismatches between hosts and targets. IOCTLs can be
+converted too.
+
+POSIX signal handling
+~~~~~~~~~~~~~~~~~~~~~
+
+QEMU can redirect to the running program all signals coming from the
+host (such as ``SIGALRM``), as well as synthesize signals from
+virtual CPU exceptions (for example ``SIGFPE`` when the program
+executes a division by zero).
+
+QEMU relies on the host kernel to emulate most signal system calls,
+for example to emulate the signal mask. On Linux, QEMU supports both
+normal and real-time signals.
+
+Threading
+~~~~~~~~~
+
+On Linux, QEMU can emulate the ``clone`` syscall and create a real
+host thread (with a separate virtual CPU) for each emulated thread.
+Note that not all targets currently emulate atomic operations
+correctly. x86 and Arm use a global lock in order to preserve their
+semantics.
 
 QEMU was conceived so that ultimately it can emulate itself. Although it
 is not very useful, it is an important test to show the power of the
-- 
2.47.2

Re: [PATCH for 10.1 03/13] docs/user: clean up headings

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:02 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> This was a slightly duff format for rst, make it use proper headings.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/user/main.rst | 50 ++++++++++++++++++++++++++--------------------
>  1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/docs/user/main.rst b/docs/user/main.rst
> index 9a1c60448c5..b8ff203c212 100644
> --- a/docs/user/main.rst
> +++ b/docs/user/main.rst
> @@ -17,28 +17,34 @@ Features
>
>  QEMU user space emulation has the following notable features:
>
> -**System call translation:**
> -   QEMU includes a generic system call translator. This means that the
> -   parameters of the system calls can be converted to fix endianness and
> -   32/64-bit mismatches between hosts and targets. IOCTLs can be
> -   converted too.
> -
> -**POSIX signal handling:**
> -   QEMU can redirect to the running program all signals coming from the
> -   host (such as ``SIGALRM``), as well as synthesize signals from
> -   virtual CPU exceptions (for example ``SIGFPE`` when the program
> -   executes a division by zero).
> -
> -   QEMU relies on the host kernel to emulate most signal system calls,
> -   for example to emulate the signal mask. On Linux, QEMU supports both
> -   normal and real-time signals.
> -
> -**Threading:**
> -   On Linux, QEMU can emulate the ``clone`` syscall and create a real
> -   host thread (with a separate virtual CPU) for each emulated thread.
> -   Note that not all targets currently emulate atomic operations
> -   correctly. x86 and Arm use a global lock in order to preserve their
> -   semantics.
> +System call translation
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +QEMU includes a generic system call translator. This means that the
> +parameters of the system calls can be converted to fix endianness
> +and 32/64-bit mismatches between hosts and targets. IOCTLs can be
> +converted too.
> +
> +POSIX signal handling
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +QEMU can redirect to the running program all signals coming from the
> +host (such as ``SIGALRM``), as well as synthesize signals from
> +virtual CPU exceptions (for example ``SIGFPE`` when the program
> +executes a division by zero).
> +
> +QEMU relies on the host kernel to emulate most signal system calls,
> +for example to emulate the signal mask. On Linux, QEMU supports both
> +normal and real-time signals.
> +
> +Threading
> +~~~~~~~~~
> +
> +On Linux, QEMU can emulate the ``clone`` syscall and create a real
> +host thread (with a separate virtual CPU) for each emulated thread.
> +Note that not all targets currently emulate atomic operations
> +correctly. x86 and Arm use a global lock in order to preserve their
> +semantics.
>
>  QEMU was conceived so that ultimately it can emulate itself. Although it
>  is not very useful, it is an important test to show the power of the
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

Re: [PATCH for 10.1 03/13] docs/user: clean up headings

[Richard Henderson]

On 7/24/25 00:59, Alex Bennée wrote:
> +Threading
> +~~~~~~~~~
> +
> +On Linux, QEMU can emulate the ``clone`` syscall and create a real
> +host thread (with a separate virtual CPU) for each emulated thread.


We might say something here about limited emulation of clone.
See CLONE_INVALID_THREAD_FLAGS.

> +Note that not all targets currently emulate atomic operations
> +correctly. x86 and Arm use a global lock in order to preserve their
> +semantics.

Wow, that's out of date.


r~

Re: [PATCH for 10.1 03/13] docs/user: clean up headings

[Richard Henderson]

On 7/24/25 15:13, Richard Henderson wrote:
> On 7/24/25 00:59, Alex Bennée wrote:
>> +Threading
>> +~~~~~~~~~
>> +
>> +On Linux, QEMU can emulate the ``clone`` syscall and create a real
>> +host thread (with a separate virtual CPU) for each emulated thread.
> 
> 
> We might say something here about limited emulation of clone.
> See CLONE_INVALID_THREAD_FLAGS.
> 
>> +Note that not all targets currently emulate atomic operations
>> +correctly. x86 and Arm use a global lock in order to preserve their
>> +semantics.
> 
> Wow, that's out of date.

I should have waited until patch 5.  :-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

[PATCH for 10.1 04/13] docs/user: slightly reword section on system calls

[Alex Bennée]

Expand the description slightly and quote ioctl(). I did ponder
mentioning something about why DRM ioctls are often missing but I see
we have the I915 ones so I guess its just no one has done them.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/user/main.rst | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/docs/user/main.rst b/docs/user/main.rst
index b8ff203c212..05de904225c 100644
--- a/docs/user/main.rst
+++ b/docs/user/main.rst
@@ -20,10 +20,14 @@ QEMU user space emulation has the following notable features:
 System call translation
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-QEMU includes a generic system call translator. This means that the
-parameters of the system calls can be converted to fix endianness
-and 32/64-bit mismatches between hosts and targets. IOCTLs can be
-converted too.
+System calls are the principle interface between user-space and the
+kernel. Generally the same system calls exist on all versions of the
+kernel so QEMU includes a generic system call translator. The
+translator takes care of adjusting endianess, 32/64 bit parameter size
+and then calling the equivalent host system call.
+
+QEMU can also adjust device specific ``ioctl()`` calls in a similar
+fashion.
 
 POSIX signal handling
 ~~~~~~~~~~~~~~~~~~~~~
-- 
2.47.2

Re: [PATCH for 10.1 04/13] docs/user: slightly reword section on system calls

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Expand the description slightly and quote ioctl(). I did ponder
> mentioning something about why DRM ioctls are often missing but I see
> we have the I915 ones so I guess its just no one has done them.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/user/main.rst | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/docs/user/main.rst b/docs/user/main.rst
> index b8ff203c212..05de904225c 100644
> --- a/docs/user/main.rst
> +++ b/docs/user/main.rst
> @@ -20,10 +20,14 @@ QEMU user space emulation has the following notable features:
>  System call translation
>  ~~~~~~~~~~~~~~~~~~~~~~~
>
> -QEMU includes a generic system call translator. This means that the
> -parameters of the system calls can be converted to fix endianness
> -and 32/64-bit mismatches between hosts and targets. IOCTLs can be
> -converted too.
> +System calls are the principle interface between user-space and the
> +kernel. Generally the same system calls exist on all versions of the
> +kernel so QEMU includes a generic system call translator. The
> +translator takes care of adjusting endianess, 32/64 bit parameter size
> +and then calling the equivalent host system call.
> +
> +QEMU can also adjust device specific ``ioctl()`` calls in a similar
> +fashion.
>
>  POSIX signal handling
>  ~~~~~~~~~~~~~~~~~~~~~
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 05/13] docs/user: expand section on threading

[Alex Bennée]

Potentially too many weasel words when describing atomic and memory
order issues.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/user/main.rst | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/user/main.rst b/docs/user/main.rst
index 05de904225c..449acd4a324 100644
--- a/docs/user/main.rst
+++ b/docs/user/main.rst
@@ -46,9 +46,14 @@ Threading
 
 On Linux, QEMU can emulate the ``clone`` syscall and create a real
 host thread (with a separate virtual CPU) for each emulated thread.
-Note that not all targets currently emulate atomic operations
-correctly. x86 and Arm use a global lock in order to preserve their
-semantics.
+However as QEMU relies on the system libc to call ``clone`` on its
+behalf we are limit the flags accepted to those it uses. Specifically
+this means flags affecting namespaces (e.g. container runtimes) are
+not supported. QEMU guest can still be run inside containers though.
+
+While QEMU does its best to emulate atomic operations properly
+differences between the host and guest memory models can cause issues
+for software that makes assumptions about the memory model.
 
 QEMU was conceived so that ultimately it can emulate itself. Although it
 is not very useful, it is an important test to show the power of the
-- 
2.47.2

Re: [PATCH for 10.1 05/13] docs/user: expand section on threading

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:02 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Potentially too many weasel words when describing atomic and memory
> order issues.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  docs/user/main.rst | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/docs/user/main.rst b/docs/user/main.rst
> index 05de904225c..449acd4a324 100644
> --- a/docs/user/main.rst
> +++ b/docs/user/main.rst
> @@ -46,9 +46,14 @@ Threading
>
>  On Linux, QEMU can emulate the ``clone`` syscall and create a real
>  host thread (with a separate virtual CPU) for each emulated thread.
> -Note that not all targets currently emulate atomic operations
> -correctly. x86 and Arm use a global lock in order to preserve their
> -semantics.
> +However as QEMU relies on the system libc to call ``clone`` on its
> +behalf we are limit the flags accepted to those it uses. Specifically

s/we are limit/we limit

> +this means flags affecting namespaces (e.g. container runtimes) are
> +not supported. QEMU guest can still be run inside containers though.

QEMU guest? Maybe write "QEMU user-mode" instead?


> +
> +While QEMU does its best to emulate atomic operations properly
> +differences between the host and guest memory models can cause issues
> +for software that makes assumptions about the memory model.
>
>  QEMU was conceived so that ultimately it can emulate itself. Although it
>  is not very useful, it is an important test to show the power of the
> --
> 2.47.2
>
>


-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

[PATCH for 10.1 06/13] tests/functional: add hypervisor test for aarch64

[Alex Bennée]

This is a simple test case that runs an image with kvmtool and
kvm-unit-tests which can validate virtualisation works. This is useful
for exercising TCG but can also be applied to any nested virt setup
which is why it doesn't specify an accelerator.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: Mark Burton <mburton@qti.qualcomm.com>
---
 tests/functional/meson.build         |  1 +
 tests/functional/test_aarch64_kvm.py | 83 ++++++++++++++++++++++++++++
 2 files changed, 84 insertions(+)
 create mode 100755 tests/functional/test_aarch64_kvm.py

diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 8bebcd4d94e..ecf965adc6c 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -89,6 +89,7 @@ tests_aarch64_system_thorough = [
   'aarch64_device_passthrough',
   'aarch64_hotplug_pci',
   'aarch64_imx8mp_evk',
+  'aarch64_kvm',
   'aarch64_raspi3',
   'aarch64_raspi4',
   'aarch64_replay',
diff --git a/tests/functional/test_aarch64_kvm.py b/tests/functional/test_aarch64_kvm.py
new file mode 100755
index 00000000000..a42d82872af
--- /dev/null
+++ b/tests/functional/test_aarch64_kvm.py
@@ -0,0 +1,83 @@
+#!/usr/bin/env python3
+#
+# Functional test that runs subsets of kvm-unit-tests on Aarch64.
+# These can run on TCG and any accelerator supporting nested
+# virtualisation.
+#
+# Copyright (c) 2025 Linaro
+#
+# Author:
+#  Alex Bennée <alex.bennee@linaro.org>
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu.machine.machine import VMLaunchFailure
+
+from qemu_test import Asset
+from qemu_test import exec_command_and_wait_for_pattern as ec_and_wait
+from qemu_test.linuxkernel import LinuxKernelTest
+
+
+class Aarch64VirtKVMTests(LinuxKernelTest):
+
+    ASSET_KVM_TEST_KERNEL = Asset(
+        'https://fileserver.linaro.org/s/HmjaxXXYHYSqbes/'
+        'download?path=%2F&files='
+        'image-with-kvm-tool-and-unit-tests.gz',
+        '34de4aaea90db5da42729e7d28b77f392c37a2f4da859f889a5234aaf0970696')
+
+    # make it easier to detect successful return to shell
+    PS1 = 'RES=[$?] # '
+    OK_CMD = 'RES=[0] # '
+
+    # base of tests
+    KUT_BASE = "/usr/share/kvm-unit-tests/"
+
+    def _launch_guest(self, kvm_mode="nvhe"):
+
+        self.set_machine('virt')
+        kernel_path = self.ASSET_KVM_TEST_KERNEL.fetch()
+
+        self.vm.set_console()
+        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+                               f"console=ttyAMA0 kvm-arm.mode={kvm_mode}")
+
+        self.vm.add_args("-cpu", "cortex-a72")
+        self.vm.add_args("-machine", "virt,gic-version=3,virtualization=on",
+                         '-kernel', kernel_path,
+                         '-append', kernel_command_line)
+        self.vm.add_args("-smp", "2", "-m", "320")
+
+        try:
+            self.vm.launch()
+        except VMLaunchFailure as excp:
+            self.log.info("unhandled launch failure: %s", excp.output)
+            raise excp
+
+        self.wait_for_console_pattern('buildroot login:')
+        ec_and_wait(self, 'root', '#')
+        ec_and_wait(self, f"export PS1='{self.PS1}'", self.OK_CMD)
+
+
+    def test_aarch64_nvhe_selftest(self):
+
+        self._launch_guest("nvhe")
+
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-setup", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-smp", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-kernel", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-user", self.OK_CMD)
+
+
+    def test_aarch64_vhe_selftest(self):
+
+        self._launch_guest("vhe")
+
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-setup", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-smp", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-kernel", self.OK_CMD)
+        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-user", self.OK_CMD)
+
+
+if __name__ == '__main__':
+    LinuxKernelTest.main()
-- 
2.47.2

Re: [PATCH for 10.1 06/13] tests/functional: add hypervisor test for aarch64

[Thomas Huth]

On 24/07/2025 12.59, Alex Bennée wrote:
> This is a simple test case that runs an image with kvmtool and
> kvm-unit-tests which can validate virtualisation works. This is useful
> for exercising TCG but can also be applied to any nested virt setup
> which is why it doesn't specify an accelerator.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> Cc: Mark Burton <mburton@qti.qualcomm.com>
> ---
>   tests/functional/meson.build         |  1 +
>   tests/functional/test_aarch64_kvm.py | 83 ++++++++++++++++++++++++++++
>   2 files changed, 84 insertions(+)
>   create mode 100755 tests/functional/test_aarch64_kvm.py
> 
> diff --git a/tests/functional/meson.build b/tests/functional/meson.build
> index 8bebcd4d94e..ecf965adc6c 100644
> --- a/tests/functional/meson.build
> +++ b/tests/functional/meson.build
> @@ -89,6 +89,7 @@ tests_aarch64_system_thorough = [
>     'aarch64_device_passthrough',
>     'aarch64_hotplug_pci',
>     'aarch64_imx8mp_evk',
> +  'aarch64_kvm',
>     'aarch64_raspi3',
>     'aarch64_raspi4',
>     'aarch64_replay',
> diff --git a/tests/functional/test_aarch64_kvm.py b/tests/functional/test_aarch64_kvm.py
> new file mode 100755
> index 00000000000..a42d82872af
> --- /dev/null
> +++ b/tests/functional/test_aarch64_kvm.py
> @@ -0,0 +1,83 @@
> +#!/usr/bin/env python3
> +#
> +# Functional test that runs subsets of kvm-unit-tests on Aarch64.
> +# These can run on TCG and any accelerator supporting nested
> +# virtualisation.
> +#
> +# Copyright (c) 2025 Linaro
> +#
> +# Author:
> +#  Alex Bennée <alex.bennee@linaro.org>
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +from qemu.machine.machine import VMLaunchFailure
> +
> +from qemu_test import Asset
> +from qemu_test import exec_command_and_wait_for_pattern as ec_and_wait
> +from qemu_test.linuxkernel import LinuxKernelTest
> +
> +
> +class Aarch64VirtKVMTests(LinuxKernelTest):
> +
> +    ASSET_KVM_TEST_KERNEL = Asset(
> +        'https://fileserver.linaro.org/s/HmjaxXXYHYSqbes/'
> +        'download?path=%2F&files='
> +        'image-with-kvm-tool-and-unit-tests.gz',
> +        '34de4aaea90db5da42729e7d28b77f392c37a2f4da859f889a5234aaf0970696')
> +
> +    # make it easier to detect successful return to shell
> +    PS1 = 'RES=[$?] # '
> +    OK_CMD = 'RES=[0] # '
> +
> +    # base of tests
> +    KUT_BASE = "/usr/share/kvm-unit-tests/"
> +
> +    def _launch_guest(self, kvm_mode="nvhe"):
> +
> +        self.set_machine('virt')
> +        kernel_path = self.ASSET_KVM_TEST_KERNEL.fetch()
> +
> +        self.vm.set_console()
> +        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> +                               f"console=ttyAMA0 kvm-arm.mode={kvm_mode}")
> +
> +        self.vm.add_args("-cpu", "cortex-a72")
> +        self.vm.add_args("-machine", "virt,gic-version=3,virtualization=on",
> +                         '-kernel', kernel_path,
> +                         '-append', kernel_command_line)
> +        self.vm.add_args("-smp", "2", "-m", "320")
> +
> +        try:
> +            self.vm.launch()
> +        except VMLaunchFailure as excp:
> +            self.log.info("unhandled launch failure: %s", excp.output)
> +            raise excp

Unless you want to intercept certain launch failures, I think it's easier to 
simply omit the "try:" and "except" here and call self.vm.launch() directly.
(you can also drop the "from qemu.machine.machine import VMLaunchFailure" in 
that case).

> +        self.wait_for_console_pattern('buildroot login:')
> +        ec_and_wait(self, 'root', '#')
> +        ec_and_wait(self, f"export PS1='{self.PS1}'", self.OK_CMD)
> +
> +

Cosmetical nit: We're normally only using one empty line between functions.

Apart from that, the test looks fine to me.

  Thomas

> +    def test_aarch64_nvhe_selftest(self):
> +
> +        self._launch_guest("nvhe")
> +
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-setup", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-smp", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-kernel", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-user", self.OK_CMD)
> +
> +
> +    def test_aarch64_vhe_selftest(self):
> +
> +        self._launch_guest("vhe")
> +
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-setup", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-smp", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-kernel", self.OK_CMD)
> +        ec_and_wait(self, f"{self.KUT_BASE}/selftest-vectors-user", self.OK_CMD)
> +
> +
> +if __name__ == '__main__':
> +    LinuxKernelTest.main()

[PATCH for 10.1 07/13] tests/tcg: skip libsyscall.so on softmmu tests

[Alex Bennée]

It isn't testing anything and just expanding the runtime of testing.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/tcg/Makefile.target | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
index af68f11664f..3d96182a7b9 100644
--- a/tests/tcg/Makefile.target
+++ b/tests/tcg/Makefile.target
@@ -155,6 +155,12 @@ VPATH+=$(PLUGIN_LIB)
 # For example, libpatch.so only needs to run against the arch-specific patch
 # target test, so we explicitly run it in the arch-specific Makefile.
 DISABLE_PLUGINS=libpatch.so
+
+# Likewise don't bother with the syscall plugin for softmmu
+ifneq ($(filter %-softmmu, $(TARGET)),)
+DISABLE_PLUGINS += libsyscall.so
+endif
+
 PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
 	$(patsubst %.c, lib%.so, $(notdir $(wildcard $(PLUGIN_SRC)/*.c))))
 
-- 
2.47.2

Re: [PATCH for 10.1 07/13] tests/tcg: skip libsyscall.so on softmmu tests

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> It isn't testing anything and just expanding the runtime of testing.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/tcg/Makefile.target | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> index af68f11664f..3d96182a7b9 100644
> --- a/tests/tcg/Makefile.target
> +++ b/tests/tcg/Makefile.target
> @@ -155,6 +155,12 @@ VPATH+=$(PLUGIN_LIB)
>  # For example, libpatch.so only needs to run against the arch-specific patch
>  # target test, so we explicitly run it in the arch-specific Makefile.
>  DISABLE_PLUGINS=libpatch.so
> +
> +# Likewise don't bother with the syscall plugin for softmmu
> +ifneq ($(filter %-softmmu, $(TARGET)),)
> +DISABLE_PLUGINS += libsyscall.so
> +endif
> +
>  PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
>         $(patsubst %.c, lib%.so, $(notdir $(wildcard $(PLUGIN_SRC)/*.c))))
>
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 08/13] tests/tcg: remove ADDITIONAL_PLUGINS_TESTS

[Alex Bennée]

We never actually used this is the end. Remove it to enable
re-factoring.

Fixes: 7cefff22d54 (tests/tcg: add mechanism to run specific tests with plugins)
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/tcg/Makefile.target | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
index 3d96182a7b9..97ebe8f9bc9 100644
--- a/tests/tcg/Makefile.target
+++ b/tests/tcg/Makefile.target
@@ -169,11 +169,10 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
 # only expand MULTIARCH_TESTS which are common on most of our targets
 # to avoid an exponential explosion as new tests are added. We also
 # add some special helpers the run-plugin- rules can use below.
-# In more, extra tests can be added using ADDITIONAL_PLUGINS_TESTS variable.
 
 ifneq ($(MULTIARCH_TESTS),)
 $(foreach p,$(PLUGINS), \
-	$(foreach t,$(MULTIARCH_TESTS) $(ADDITIONAL_PLUGINS_TESTS),\
+	$(foreach t,$(MULTIARCH_TESTS),\
 		$(eval run-plugin-$(t)-with-$(p): $t $p) \
 		$(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
 endif # MULTIARCH_TESTS
-- 
2.47.2

Re: [PATCH for 10.1 08/13] tests/tcg: remove ADDITIONAL_PLUGINS_TESTS

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> We never actually used this is the end. Remove it to enable
> re-factoring.
>
> Fixes: 7cefff22d54 (tests/tcg: add mechanism to run specific tests with plugins)
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/tcg/Makefile.target | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> index 3d96182a7b9..97ebe8f9bc9 100644
> --- a/tests/tcg/Makefile.target
> +++ b/tests/tcg/Makefile.target
> @@ -169,11 +169,10 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
>  # only expand MULTIARCH_TESTS which are common on most of our targets
>  # to avoid an exponential explosion as new tests are added. We also
>  # add some special helpers the run-plugin- rules can use below.
> -# In more, extra tests can be added using ADDITIONAL_PLUGINS_TESTS variable.
>
>  ifneq ($(MULTIARCH_TESTS),)
>  $(foreach p,$(PLUGINS), \
> -       $(foreach t,$(MULTIARCH_TESTS) $(ADDITIONAL_PLUGINS_TESTS),\
> +       $(foreach t,$(MULTIARCH_TESTS),\
>                 $(eval run-plugin-$(t)-with-$(p): $t $p) \
>                 $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
>  endif # MULTIARCH_TESTS
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 09/13] tests/tcg: don't include multiarch tests if not supported

[Alex Bennée]

We are about to change the way the plugin runs are done and having
this included by default will complicate things.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/tcg/Makefile.target                          | 6 ++++++
 tests/tcg/multiarch/system/Makefile.softmmu-target | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
index 97ebe8f9bc9..a12b15637ea 100644
--- a/tests/tcg/Makefile.target
+++ b/tests/tcg/Makefile.target
@@ -127,8 +127,14 @@ else
 # build options for bare programs are usually pretty different. They
 # are expected to provide their own build recipes.
 EXTRA_CFLAGS += -ffreestanding -fno-stack-protector
+
+# We skip the multiarch tests if the target hasn't provided a boot.S
+MULTIARCH_SOFTMMU_TARGETS = i386 alpha aarch64 arm loongarch64 s390x x86_64
+
+ifneq ($(filter $(TARGET_NAME),$(MULTIARCH_SOFTMMU_TARGETS)),)
 -include $(SRC_PATH)/tests/tcg/minilib/Makefile.target
 -include $(SRC_PATH)/tests/tcg/multiarch/system/Makefile.softmmu-target
+endif
 -include $(SRC_PATH)/tests/tcg/$(TARGET_NAME)/Makefile.softmmu-target
 
 endif
diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
index 07be001102b..5acf2700812 100644
--- a/tests/tcg/multiarch/system/Makefile.softmmu-target
+++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
@@ -6,6 +6,11 @@
 # architecture to add to the test dependencies and deal with the
 # complications of building.
 #
+# To support the multiarch guests the target arch needs to provide a
+# boot.S that jumps to main and provides a __sys_outc functions.
+# Remember to update MULTIARCH_SOFTMMU_TARGETS in the tcg test
+# Makefile.target when this is done.
+#
 
 MULTIARCH_SRC=$(SRC_PATH)/tests/tcg/multiarch
 MULTIARCH_SYSTEM_SRC=$(MULTIARCH_SRC)/system
-- 
2.47.2

Re: [PATCH for 10.1 09/13] tests/tcg: don't include multiarch tests if not supported

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:01 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> We are about to change the way the plugin runs are done and having
> this included by default will complicate things.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/tcg/Makefile.target                          | 6 ++++++
>  tests/tcg/multiarch/system/Makefile.softmmu-target | 5 +++++
>  2 files changed, 11 insertions(+)
>
> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> index 97ebe8f9bc9..a12b15637ea 100644
> --- a/tests/tcg/Makefile.target
> +++ b/tests/tcg/Makefile.target
> @@ -127,8 +127,14 @@ else
>  # build options for bare programs are usually pretty different. They
>  # are expected to provide their own build recipes.
>  EXTRA_CFLAGS += -ffreestanding -fno-stack-protector
> +
> +# We skip the multiarch tests if the target hasn't provided a boot.S
> +MULTIARCH_SOFTMMU_TARGETS = i386 alpha aarch64 arm loongarch64 s390x x86_64
> +
> +ifneq ($(filter $(TARGET_NAME),$(MULTIARCH_SOFTMMU_TARGETS)),)
>  -include $(SRC_PATH)/tests/tcg/minilib/Makefile.target
>  -include $(SRC_PATH)/tests/tcg/multiarch/system/Makefile.softmmu-target
> +endif
>  -include $(SRC_PATH)/tests/tcg/$(TARGET_NAME)/Makefile.softmmu-target
>
>  endif
> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
> index 07be001102b..5acf2700812 100644
> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
> @@ -6,6 +6,11 @@
>  # architecture to add to the test dependencies and deal with the
>  # complications of building.
>  #
> +# To support the multiarch guests the target arch needs to provide a
> +# boot.S that jumps to main and provides a __sys_outc functions.

s/functions/function

> +# Remember to update MULTIARCH_SOFTMMU_TARGETS in the tcg test
> +# Makefile.target when this is done.
> +#
>
>  MULTIARCH_SRC=$(SRC_PATH)/tests/tcg/multiarch
>  MULTIARCH_SYSTEM_SRC=$(MULTIARCH_SRC)/system
> --
> 2.47.2
>
>

Otherwise

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 10/13] configure: expose PYTHON to test/tcg/config-host.mak

[Alex Bennée]

This will be useful for making $shell calls to something more flexible
than the shell builtins.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 95f67c1a827..825057ebf15 100755
--- a/configure
+++ b/configure
@@ -1800,6 +1800,7 @@ echo "SRC_PATH=$source_path" >> tests/tcg/$config_host_mak
 if test "$plugins" = "yes" ; then
     echo "CONFIG_PLUGIN=y" >> tests/tcg/$config_host_mak
 fi
+echo "PYTHON=$python" >> tests/tcg/$config_host_mak
 
 tcg_tests_targets=
 for target in $target_list; do
-- 
2.47.2

Re: [PATCH for 10.1 10/13] configure: expose PYTHON to test/tcg/config-host.mak

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:01 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> This will be useful for making $shell calls to something more flexible
> than the shell builtins.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  configure | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configure b/configure
> index 95f67c1a827..825057ebf15 100755
> --- a/configure
> +++ b/configure
> @@ -1800,6 +1800,7 @@ echo "SRC_PATH=$source_path" >> tests/tcg/$config_host_mak
>  if test "$plugins" = "yes" ; then
>      echo "CONFIG_PLUGIN=y" >> tests/tcg/$config_host_mak
>  fi
> +echo "PYTHON=$python" >> tests/tcg/$config_host_mak
>
>  tcg_tests_targets=
>  for target in $target_list; do
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Alex Bennée]

As our set of multiarch tests has grown the practice of running every
plugin with every test is becoming unsustainable. If we switch to
ensuring every test gets run with at least one plugin we can speed
things up.

Some plugins do need to be run with specific tests (for example the
memory instrumentation test). We can handle this by manually adding
them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
so we don't enable the runs when plugins are not enabled.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
 tests/tcg/multiarch/Makefile.target           |  8 +++++--
 .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
index a12b15637ea..18afd5be194 100644
--- a/tests/tcg/Makefile.target
+++ b/tests/tcg/Makefile.target
@@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
 # We need to ensure expand the run-plugin-TEST-with-PLUGIN
 # pre-requistes manually here as we can't use stems to handle it. We
 # only expand MULTIARCH_TESTS which are common on most of our targets
-# to avoid an exponential explosion as new tests are added. We also
-# add some special helpers the run-plugin- rules can use below.
+# and rotate the plugins so we don't grow too out of control as new
+# tests are added. Plugins that need to run with a specific test
+# should ensure they add their combination to EXTRA_RUNS.
 
 ifneq ($(MULTIARCH_TESTS),)
-$(foreach p,$(PLUGINS), \
-	$(foreach t,$(MULTIARCH_TESTS),\
-		$(eval run-plugin-$(t)-with-$(p): $t $p) \
-		$(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
+
+NUM_PLUGINS := $(words $(PLUGINS))
+NUM_TESTS := $(words $(MULTIARCH_TESTS))
+
+define mod_plus_one
+  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
+endef
+
+$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
+	$(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
+	$(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
+	$(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
+	$(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
+
 endif # MULTIARCH_TESTS
 endif # CONFIG_PLUGIN
 
diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
index bfdf7197a7b..38345ff8805 100644
--- a/tests/tcg/multiarch/Makefile.target
+++ b/tests/tcg/multiarch/Makefile.target
@@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
 TESTS += semihosting semiconsole
 endif
 
+test-plugin-mem-access: CFLAGS+=-pthread -O0
+test-plugin-mem-access: LDFLAGS+=-pthread -O0
+
+ifeq ($(CONFIG_PLUGIN),y)
 # Test plugin memory access instrumentation
 run-plugin-test-plugin-mem-access-with-libmem.so: \
 	PLUGIN_ARGS=$(COMMA)print-accesses=true
@@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
 	$(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
 	$(QEMU) $<
 
-test-plugin-mem-access: CFLAGS+=-pthread -O0
-test-plugin-mem-access: LDFLAGS+=-pthread -O0
+EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
+endif
 
 # Update TESTS
 TESTS += $(MULTIARCH_TESTS)
diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
index 5acf2700812..4171b4e6aa0 100644
--- a/tests/tcg/multiarch/system/Makefile.softmmu-target
+++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
@@ -71,8 +71,11 @@ endif
 MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
 	run-gdbstub-untimely-packet run-gdbstub-registers
 
+ifeq ($(CONFIG_PLUGIN),y)
 # Test plugin memory access instrumentation
-run-plugin-memory-with-libmem.so: 		\
-	PLUGIN_ARGS=$(COMMA)region-summary=true
-run-plugin-memory-with-libmem.so: 		\
-	CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
+run-plugin-memory-with-libmem.so: memory libmem.so
+run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
+run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
+
+EXTRA_RUNS += run-plugin-memory-with-libmem.so
+endif
-- 
2.47.2

Re: [PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> As our set of multiarch tests has grown the practice of running every
> plugin with every test is becoming unsustainable. If we switch to
> ensuring every test gets run with at least one plugin we can speed
> things up.
>
> Some plugins do need to be run with specific tests (for example the
> memory instrumentation test). We can handle this by manually adding
> them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
> so we don't enable the runs when plugins are not enabled.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
>  tests/tcg/multiarch/Makefile.target           |  8 +++++--
>  .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
>  3 files changed, 30 insertions(+), 12 deletions(-)
>
> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> index a12b15637ea..18afd5be194 100644
> --- a/tests/tcg/Makefile.target
> +++ b/tests/tcg/Makefile.target
> @@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
>  # We need to ensure expand the run-plugin-TEST-with-PLUGIN
>  # pre-requistes manually here as we can't use stems to handle it. We
>  # only expand MULTIARCH_TESTS which are common on most of our targets
> -# to avoid an exponential explosion as new tests are added. We also
> -# add some special helpers the run-plugin- rules can use below.
> +# and rotate the plugins so we don't grow too out of control as new
> +# tests are added. Plugins that need to run with a specific test
> +# should ensure they add their combination to EXTRA_RUNS.
>
>  ifneq ($(MULTIARCH_TESTS),)
> -$(foreach p,$(PLUGINS), \
> -       $(foreach t,$(MULTIARCH_TESTS),\
> -               $(eval run-plugin-$(t)-with-$(p): $t $p) \
> -               $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
> +
> +NUM_PLUGINS := $(words $(PLUGINS))
> +NUM_TESTS := $(words $(MULTIARCH_TESTS))
> +
> +define mod_plus_one
> +  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
> +endef
> +
> +$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
> +       $(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
> +       $(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
> +       $(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
> +       $(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
> +
>  endif # MULTIARCH_TESTS
>  endif # CONFIG_PLUGIN
>
> diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
> index bfdf7197a7b..38345ff8805 100644
> --- a/tests/tcg/multiarch/Makefile.target
> +++ b/tests/tcg/multiarch/Makefile.target
> @@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
>  TESTS += semihosting semiconsole
>  endif
>
> +test-plugin-mem-access: CFLAGS+=-pthread -O0
> +test-plugin-mem-access: LDFLAGS+=-pthread -O0
> +
> +ifeq ($(CONFIG_PLUGIN),y)
>  # Test plugin memory access instrumentation
>  run-plugin-test-plugin-mem-access-with-libmem.so: \
>         PLUGIN_ARGS=$(COMMA)print-accesses=true
> @@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
>         $(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
>         $(QEMU) $<
>
> -test-plugin-mem-access: CFLAGS+=-pthread -O0
> -test-plugin-mem-access: LDFLAGS+=-pthread -O0
> +EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
> +endif
>
>  # Update TESTS
>  TESTS += $(MULTIARCH_TESTS)
> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
> index 5acf2700812..4171b4e6aa0 100644
> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
> @@ -71,8 +71,11 @@ endif
>  MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
>         run-gdbstub-untimely-packet run-gdbstub-registers
>
> +ifeq ($(CONFIG_PLUGIN),y)
>  # Test plugin memory access instrumentation
> -run-plugin-memory-with-libmem.so:              \
> -       PLUGIN_ARGS=$(COMMA)region-summary=true
> -run-plugin-memory-with-libmem.so:              \
> -       CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> +run-plugin-memory-with-libmem.so: memory libmem.so

Hm why wasn't this needed before this change?

I see the make `memory` target sets CHECK_UNALIGNED but where is
libmem.so target coming from?

> +run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
> +run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> +
> +EXTRA_RUNS += run-plugin-memory-with-libmem.so
> +endif
> --
> 2.47.2
>
>

Re: [PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Alex Bennée]

Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:

> On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> As our set of multiarch tests has grown the practice of running every
>> plugin with every test is becoming unsustainable. If we switch to
>> ensuring every test gets run with at least one plugin we can speed
>> things up.
>>
>> Some plugins do need to be run with specific tests (for example the
>> memory instrumentation test). We can handle this by manually adding
>> them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
>> so we don't enable the runs when plugins are not enabled.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
>>  tests/tcg/multiarch/Makefile.target           |  8 +++++--
>>  .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
>>  3 files changed, 30 insertions(+), 12 deletions(-)
>>
>> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
>> index a12b15637ea..18afd5be194 100644
>> --- a/tests/tcg/Makefile.target
>> +++ b/tests/tcg/Makefile.target
>> @@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
>>  # We need to ensure expand the run-plugin-TEST-with-PLUGIN
>>  # pre-requistes manually here as we can't use stems to handle it. We
>>  # only expand MULTIARCH_TESTS which are common on most of our targets
>> -# to avoid an exponential explosion as new tests are added. We also
>> -# add some special helpers the run-plugin- rules can use below.
>> +# and rotate the plugins so we don't grow too out of control as new
>> +# tests are added. Plugins that need to run with a specific test
>> +# should ensure they add their combination to EXTRA_RUNS.
>>
>>  ifneq ($(MULTIARCH_TESTS),)
>> -$(foreach p,$(PLUGINS), \
>> -       $(foreach t,$(MULTIARCH_TESTS),\
>> -               $(eval run-plugin-$(t)-with-$(p): $t $p) \
>> -               $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
>> +
>> +NUM_PLUGINS := $(words $(PLUGINS))
>> +NUM_TESTS := $(words $(MULTIARCH_TESTS))
>> +
>> +define mod_plus_one
>> +  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
>> +endef
>> +
>> +$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
>> +       $(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
>> +       $(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
>> +       $(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
>> +       $(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
>> +
>>  endif # MULTIARCH_TESTS
>>  endif # CONFIG_PLUGIN
>>
>> diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
>> index bfdf7197a7b..38345ff8805 100644
>> --- a/tests/tcg/multiarch/Makefile.target
>> +++ b/tests/tcg/multiarch/Makefile.target
>> @@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
>>  TESTS += semihosting semiconsole
>>  endif
>>
>> +test-plugin-mem-access: CFLAGS+=-pthread -O0
>> +test-plugin-mem-access: LDFLAGS+=-pthread -O0
>> +
>> +ifeq ($(CONFIG_PLUGIN),y)
>>  # Test plugin memory access instrumentation
>>  run-plugin-test-plugin-mem-access-with-libmem.so: \
>>         PLUGIN_ARGS=$(COMMA)print-accesses=true
>> @@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
>>         $(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
>>         $(QEMU) $<
>>
>> -test-plugin-mem-access: CFLAGS+=-pthread -O0
>> -test-plugin-mem-access: LDFLAGS+=-pthread -O0
>> +EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
>> +endif
>>
>>  # Update TESTS
>>  TESTS += $(MULTIARCH_TESTS)
>> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
>> index 5acf2700812..4171b4e6aa0 100644
>> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
>> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
>> @@ -71,8 +71,11 @@ endif
>>  MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
>>         run-gdbstub-untimely-packet run-gdbstub-registers
>>
>> +ifeq ($(CONFIG_PLUGIN),y)
>>  # Test plugin memory access instrumentation
>> -run-plugin-memory-with-libmem.so:              \
>> -       PLUGIN_ARGS=$(COMMA)region-summary=true
>> -run-plugin-memory-with-libmem.so:              \
>> -       CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
>> +run-plugin-memory-with-libmem.so: memory libmem.so
>
> Hm why wasn't this needed before this change?
>
> I see the make `memory` target sets CHECK_UNALIGNED but where is
> libmem.so target coming from?
>
>> +run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
>> +run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
>> +
>> +EXTRA_RUNS += run-plugin-memory-with-libmem.so

Because we add it to EXTRA_RUNS so we don't want that if plugins won't
work. We could just wrap EXTRA_RUNS but the rest of the recipe is moot
at that point anyway.

>> +endif
>> --
>> 2.47.2
>>
>>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 3:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> As our set of multiarch tests has grown the practice of running every
> >> plugin with every test is becoming unsustainable. If we switch to
> >> ensuring every test gets run with at least one plugin we can speed
> >> things up.
> >>
> >> Some plugins do need to be run with specific tests (for example the
> >> memory instrumentation test). We can handle this by manually adding
> >> them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
> >> so we don't enable the runs when plugins are not enabled.
> >>
> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> ---
> >>  tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
> >>  tests/tcg/multiarch/Makefile.target           |  8 +++++--
> >>  .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
> >>  3 files changed, 30 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> >> index a12b15637ea..18afd5be194 100644
> >> --- a/tests/tcg/Makefile.target
> >> +++ b/tests/tcg/Makefile.target
> >> @@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
> >>  # We need to ensure expand the run-plugin-TEST-with-PLUGIN
> >>  # pre-requistes manually here as we can't use stems to handle it. We
> >>  # only expand MULTIARCH_TESTS which are common on most of our targets
> >> -# to avoid an exponential explosion as new tests are added. We also
> >> -# add some special helpers the run-plugin- rules can use below.
> >> +# and rotate the plugins so we don't grow too out of control as new
> >> +# tests are added. Plugins that need to run with a specific test
> >> +# should ensure they add their combination to EXTRA_RUNS.
> >>
> >>  ifneq ($(MULTIARCH_TESTS),)
> >> -$(foreach p,$(PLUGINS), \
> >> -       $(foreach t,$(MULTIARCH_TESTS),\
> >> -               $(eval run-plugin-$(t)-with-$(p): $t $p) \
> >> -               $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
> >> +
> >> +NUM_PLUGINS := $(words $(PLUGINS))
> >> +NUM_TESTS := $(words $(MULTIARCH_TESTS))
> >> +
> >> +define mod_plus_one
> >> +  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
> >> +endef
> >> +
> >> +$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
> >> +       $(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
> >> +       $(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
> >> +       $(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
> >> +       $(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
> >> +
> >>  endif # MULTIARCH_TESTS
> >>  endif # CONFIG_PLUGIN
> >>
> >> diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
> >> index bfdf7197a7b..38345ff8805 100644
> >> --- a/tests/tcg/multiarch/Makefile.target
> >> +++ b/tests/tcg/multiarch/Makefile.target
> >> @@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
> >>  TESTS += semihosting semiconsole
> >>  endif
> >>
> >> +test-plugin-mem-access: CFLAGS+=-pthread -O0
> >> +test-plugin-mem-access: LDFLAGS+=-pthread -O0
> >> +
> >> +ifeq ($(CONFIG_PLUGIN),y)
> >>  # Test plugin memory access instrumentation
> >>  run-plugin-test-plugin-mem-access-with-libmem.so: \
> >>         PLUGIN_ARGS=$(COMMA)print-accesses=true
> >> @@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
> >>         $(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
> >>         $(QEMU) $<
> >>
> >> -test-plugin-mem-access: CFLAGS+=-pthread -O0
> >> -test-plugin-mem-access: LDFLAGS+=-pthread -O0
> >> +EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
> >> +endif
> >>
> >>  # Update TESTS
> >>  TESTS += $(MULTIARCH_TESTS)
> >> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> index 5acf2700812..4171b4e6aa0 100644
> >> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> @@ -71,8 +71,11 @@ endif
> >>  MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
> >>         run-gdbstub-untimely-packet run-gdbstub-registers
> >>
> >> +ifeq ($(CONFIG_PLUGIN),y)
> >>  # Test plugin memory access instrumentation
> >> -run-plugin-memory-with-libmem.so:              \
> >> -       PLUGIN_ARGS=$(COMMA)region-summary=true
> >> -run-plugin-memory-with-libmem.so:              \
> >> -       CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> >> +run-plugin-memory-with-libmem.so: memory libmem.so
> >
> > Hm why wasn't this needed before this change?
> >
> > I see the make `memory` target sets CHECK_UNALIGNED but where is
> > libmem.so target coming from?
> >
> >> +run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
> >> +run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> >> +
> >> +EXTRA_RUNS += run-plugin-memory-with-libmem.so
>
> Because we add it to EXTRA_RUNS so we don't want that if plugins won't
> work. We could just wrap EXTRA_RUNS but the rest of the recipe is moot
> at that point anyway.

I am asking about the line

> +run-plugin-memory-with-libmem.so: memory libmem.so

Which adds two make target prerequisites `memory` and `libmem.so`, I
don't see where they came from, or maybe I am not understanding the
makefile logic here correctly.

>
> >> +endif
> >> --
> >> 2.47.2
> >>
> >>
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

Re: [PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Alex Bennée]

Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:

> On Thu, Jul 24, 2025 at 3:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>>
>> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>> >>
>> >> As our set of multiarch tests has grown the practice of running every
>> >> plugin with every test is becoming unsustainable. If we switch to
>> >> ensuring every test gets run with at least one plugin we can speed
>> >> things up.
>> >>
>> >> Some plugins do need to be run with specific tests (for example the
>> >> memory instrumentation test). We can handle this by manually adding
>> >> them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
>> >> so we don't enable the runs when plugins are not enabled.
>> >>
>> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> >> ---
>> >>  tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
>> >>  tests/tcg/multiarch/Makefile.target           |  8 +++++--
>> >>  .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
>> >>  3 files changed, 30 insertions(+), 12 deletions(-)
>> >>
>> >> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
>> >> index a12b15637ea..18afd5be194 100644
>> >> --- a/tests/tcg/Makefile.target
>> >> +++ b/tests/tcg/Makefile.target
>> >> @@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
>> >>  # We need to ensure expand the run-plugin-TEST-with-PLUGIN
>> >>  # pre-requistes manually here as we can't use stems to handle it. We
>> >>  # only expand MULTIARCH_TESTS which are common on most of our targets
>> >> -# to avoid an exponential explosion as new tests are added. We also
>> >> -# add some special helpers the run-plugin- rules can use below.
>> >> +# and rotate the plugins so we don't grow too out of control as new
>> >> +# tests are added. Plugins that need to run with a specific test
>> >> +# should ensure they add their combination to EXTRA_RUNS.
>> >>
>> >>  ifneq ($(MULTIARCH_TESTS),)
>> >> -$(foreach p,$(PLUGINS), \
>> >> -       $(foreach t,$(MULTIARCH_TESTS),\
>> >> -               $(eval run-plugin-$(t)-with-$(p): $t $p) \
>> >> -               $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
>> >> +
>> >> +NUM_PLUGINS := $(words $(PLUGINS))
>> >> +NUM_TESTS := $(words $(MULTIARCH_TESTS))
>> >> +
>> >> +define mod_plus_one
>> >> +  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
>> >> +endef
>> >> +
>> >> +$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
>> >> +       $(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
>> >> +       $(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
>> >> +       $(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
>> >> +       $(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
>> >> +
>> >>  endif # MULTIARCH_TESTS
>> >>  endif # CONFIG_PLUGIN
>> >>
>> >> diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
>> >> index bfdf7197a7b..38345ff8805 100644
>> >> --- a/tests/tcg/multiarch/Makefile.target
>> >> +++ b/tests/tcg/multiarch/Makefile.target
>> >> @@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
>> >>  TESTS += semihosting semiconsole
>> >>  endif
>> >>
>> >> +test-plugin-mem-access: CFLAGS+=-pthread -O0
>> >> +test-plugin-mem-access: LDFLAGS+=-pthread -O0
>> >> +
>> >> +ifeq ($(CONFIG_PLUGIN),y)
>> >>  # Test plugin memory access instrumentation
>> >>  run-plugin-test-plugin-mem-access-with-libmem.so: \
>> >>         PLUGIN_ARGS=$(COMMA)print-accesses=true
>> >> @@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
>> >>         $(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
>> >>         $(QEMU) $<
>> >>
>> >> -test-plugin-mem-access: CFLAGS+=-pthread -O0
>> >> -test-plugin-mem-access: LDFLAGS+=-pthread -O0
>> >> +EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
>> >> +endif
>> >>
>> >>  # Update TESTS
>> >>  TESTS += $(MULTIARCH_TESTS)
>> >> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
>> >> index 5acf2700812..4171b4e6aa0 100644
>> >> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
>> >> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
>> >> @@ -71,8 +71,11 @@ endif
>> >>  MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
>> >>         run-gdbstub-untimely-packet run-gdbstub-registers
>> >>
>> >> +ifeq ($(CONFIG_PLUGIN),y)
>> >>  # Test plugin memory access instrumentation
>> >> -run-plugin-memory-with-libmem.so:              \
>> >> -       PLUGIN_ARGS=$(COMMA)region-summary=true
>> >> -run-plugin-memory-with-libmem.so:              \
>> >> -       CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
>> >> +run-plugin-memory-with-libmem.so: memory libmem.so
>> >
>> > Hm why wasn't this needed before this change?
>> >
>> > I see the make `memory` target sets CHECK_UNALIGNED but where is
>> > libmem.so target coming from?
>> >
>> >> +run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
>> >> +run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
>> >> +
>> >> +EXTRA_RUNS += run-plugin-memory-with-libmem.so
>>
>> Because we add it to EXTRA_RUNS so we don't want that if plugins won't
>> work. We could just wrap EXTRA_RUNS but the rest of the recipe is moot
>> at that point anyway.
>
> I am asking about the line
>
>> +run-plugin-memory-with-libmem.so: memory libmem.so
>
> Which adds two make target prerequisites `memory` and `libmem.so`, I
> don't see where they came from, or maybe I am not understanding the
> makefile logic here correctly.

Originally we generated the pre-reqs in the:

  $(foreach p,$(PLUGINS), \
      $(foreach t,$(MULTIARCH_TESTS),\

loop. Now that doesn't cover every combination we need to add an
explicit prereq for the test case we know we will run.

>
>>
>> >> +endif
>> >> --
>> >> 2.47.2
>> >>
>> >>
>>
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH for 10.1 11/13] tests/tcg: reduce the number of plugin tests combinations

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 3:48 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
> > On Thu, Jul 24, 2025 at 3:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
> >>
> >> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >> >>
> >> >> As our set of multiarch tests has grown the practice of running every
> >> >> plugin with every test is becoming unsustainable. If we switch to
> >> >> ensuring every test gets run with at least one plugin we can speed
> >> >> things up.
> >> >>
> >> >> Some plugins do need to be run with specific tests (for example the
> >> >> memory instrumentation test). We can handle this by manually adding
> >> >> them to EXTRA_RUNS. We also need to wrap rules in a CONFIG_PLUGIN test
> >> >> so we don't enable the runs when plugins are not enabled.
> >> >>
> >> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> >> ---
> >> >>  tests/tcg/Makefile.target                     | 23 ++++++++++++++-----
> >> >>  tests/tcg/multiarch/Makefile.target           |  8 +++++--
> >> >>  .../multiarch/system/Makefile.softmmu-target  | 11 +++++----
> >> >>  3 files changed, 30 insertions(+), 12 deletions(-)
> >> >>
> >> >> diff --git a/tests/tcg/Makefile.target b/tests/tcg/Makefile.target
> >> >> index a12b15637ea..18afd5be194 100644
> >> >> --- a/tests/tcg/Makefile.target
> >> >> +++ b/tests/tcg/Makefile.target
> >> >> @@ -173,14 +173,25 @@ PLUGINS=$(filter-out $(DISABLE_PLUGINS), \
> >> >>  # We need to ensure expand the run-plugin-TEST-with-PLUGIN
> >> >>  # pre-requistes manually here as we can't use stems to handle it. We
> >> >>  # only expand MULTIARCH_TESTS which are common on most of our targets
> >> >> -# to avoid an exponential explosion as new tests are added. We also
> >> >> -# add some special helpers the run-plugin- rules can use below.
> >> >> +# and rotate the plugins so we don't grow too out of control as new
> >> >> +# tests are added. Plugins that need to run with a specific test
> >> >> +# should ensure they add their combination to EXTRA_RUNS.
> >> >>
> >> >>  ifneq ($(MULTIARCH_TESTS),)
> >> >> -$(foreach p,$(PLUGINS), \
> >> >> -       $(foreach t,$(MULTIARCH_TESTS),\
> >> >> -               $(eval run-plugin-$(t)-with-$(p): $t $p) \
> >> >> -               $(eval RUN_TESTS+=run-plugin-$(t)-with-$(p))))
> >> >> +
> >> >> +NUM_PLUGINS := $(words $(PLUGINS))
> >> >> +NUM_TESTS := $(words $(MULTIARCH_TESTS))
> >> >> +
> >> >> +define mod_plus_one
> >> >> +  $(shell $(PYTHON) -c "print( ($(1) % $(2)) + 1 )")
> >> >> +endef
> >> >> +
> >> >> +$(foreach _idx, $(shell seq 1 $(NUM_TESTS)), \
> >> >> +       $(eval _test := $(word $(_idx), $(MULTIARCH_TESTS))) \
> >> >> +       $(eval _plugin := $(word $(call mod_plus_one, $(_idx), $(NUM_PLUGINS)), $(PLUGINS))) \
> >> >> +       $(eval run-plugin-$(_test)-with-$(_plugin): $(_test) $(_plugin)) \
> >> >> +       $(eval RUN_TESTS+=run-plugin-$(_test)-with-$(_plugin)))
> >> >> +
> >> >>  endif # MULTIARCH_TESTS
> >> >>  endif # CONFIG_PLUGIN
> >> >>
> >> >> diff --git a/tests/tcg/multiarch/Makefile.target b/tests/tcg/multiarch/Makefile.target
> >> >> index bfdf7197a7b..38345ff8805 100644
> >> >> --- a/tests/tcg/multiarch/Makefile.target
> >> >> +++ b/tests/tcg/multiarch/Makefile.target
> >> >> @@ -189,6 +189,10 @@ run-plugin-semiconsole-with-%:
> >> >>  TESTS += semihosting semiconsole
> >> >>  endif
> >> >>
> >> >> +test-plugin-mem-access: CFLAGS+=-pthread -O0
> >> >> +test-plugin-mem-access: LDFLAGS+=-pthread -O0
> >> >> +
> >> >> +ifeq ($(CONFIG_PLUGIN),y)
> >> >>  # Test plugin memory access instrumentation
> >> >>  run-plugin-test-plugin-mem-access-with-libmem.so: \
> >> >>         PLUGIN_ARGS=$(COMMA)print-accesses=true
> >> >> @@ -197,8 +201,8 @@ run-plugin-test-plugin-mem-access-with-libmem.so: \
> >> >>         $(SRC_PATH)/tests/tcg/multiarch/check-plugin-output.sh \
> >> >>         $(QEMU) $<
> >> >>
> >> >> -test-plugin-mem-access: CFLAGS+=-pthread -O0
> >> >> -test-plugin-mem-access: LDFLAGS+=-pthread -O0
> >> >> +EXTRA_RUNS += run-plugin-test-plugin-mem-access-with-libmem.so
> >> >> +endif
> >> >>
> >> >>  # Update TESTS
> >> >>  TESTS += $(MULTIARCH_TESTS)
> >> >> diff --git a/tests/tcg/multiarch/system/Makefile.softmmu-target b/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> >> index 5acf2700812..4171b4e6aa0 100644
> >> >> --- a/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> >> +++ b/tests/tcg/multiarch/system/Makefile.softmmu-target
> >> >> @@ -71,8 +71,11 @@ endif
> >> >>  MULTIARCH_RUNS += run-gdbstub-memory run-gdbstub-interrupt \
> >> >>         run-gdbstub-untimely-packet run-gdbstub-registers
> >> >>
> >> >> +ifeq ($(CONFIG_PLUGIN),y)
> >> >>  # Test plugin memory access instrumentation
> >> >> -run-plugin-memory-with-libmem.so:              \
> >> >> -       PLUGIN_ARGS=$(COMMA)region-summary=true
> >> >> -run-plugin-memory-with-libmem.so:              \
> >> >> -       CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> >> >> +run-plugin-memory-with-libmem.so: memory libmem.so
> >> >
> >> > Hm why wasn't this needed before this change?
> >> >
> >> > I see the make `memory` target sets CHECK_UNALIGNED but where is
> >> > libmem.so target coming from?
> >> >
> >> >> +run-plugin-memory-with-libmem.so: PLUGIN_ARGS=$(COMMA)region-summary=true
> >> >> +run-plugin-memory-with-libmem.so: CHECK_PLUGIN_OUTPUT_COMMAND=$(MULTIARCH_SYSTEM_SRC)/validate-memory-counts.py $@.out
> >> >> +
> >> >> +EXTRA_RUNS += run-plugin-memory-with-libmem.so
> >>
> >> Because we add it to EXTRA_RUNS so we don't want that if plugins won't
> >> work. We could just wrap EXTRA_RUNS but the rest of the recipe is moot
> >> at that point anyway.
> >
> > I am asking about the line
> >
> >> +run-plugin-memory-with-libmem.so: memory libmem.so
> >
> > Which adds two make target prerequisites `memory` and `libmem.so`, I
> > don't see where they came from, or maybe I am not understanding the
> > makefile logic here correctly.
>
> Originally we generated the pre-reqs in the:
>
>   $(foreach p,$(PLUGINS), \
>       $(foreach t,$(MULTIARCH_TESTS),\
>
> loop. Now that doesn't cover every combination we need to add an
> explicit prereq for the test case we know we will run.

Ah thanks, that clears it up. The equivalent is specifically this
deleted line: $(eval run-plugin-$(t)-with-$(p): $t $p)

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

> >
> >>
> >> >> +endif
> >> >> --
> >> >> 2.47.2
> >> >>
> >> >>
> >>
> >> --
> >> Alex Bennée
> >> Virtualisation Tech Lead @ Linaro
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

[PATCH for 10.1 12/13] tests/docker: add --arch-only to qemu deps for all-test-cross

[Alex Bennée]

If we want to build this container on non-x86 systems we might not
have all the cross-compilers needed for the ROM blobs we don't
actually build. Use --arch-only to avoid stalling on these missing
bits.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/docker/dockerfiles/debian-all-test-cross.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
index 8ab244e018a..5aa43749ebe 100644
--- a/tests/docker/dockerfiles/debian-all-test-cross.docker
+++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
@@ -15,7 +15,7 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
     apt-get update && \
     apt-get install -y eatmydata && \
     eatmydata apt-get dist-upgrade -y && \
-    apt build-dep -yy qemu
+    apt build-dep -yy --arch-only qemu
 
 # Add extra build tools and as many cross compilers as we can for testing
 RUN DEBIAN_FRONTEND=noninteractive eatmydata \
-- 
2.47.2

Re: [PATCH for 10.1 12/13] tests/docker: add --arch-only to qemu deps for all-test-cross

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> If we want to build this container on non-x86 systems we might not
> have all the cross-compilers needed for the ROM blobs we don't
> actually build. Use --arch-only to avoid stalling on these missing
> bits.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/docker/dockerfiles/debian-all-test-cross.docker | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
> index 8ab244e018a..5aa43749ebe 100644
> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
> @@ -15,7 +15,7 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
>      apt-get update && \
>      apt-get install -y eatmydata && \
>      eatmydata apt-get dist-upgrade -y && \
> -    apt build-dep -yy qemu
> +    apt build-dep -yy --arch-only qemu
>
>  # Add extra build tools and as many cross compilers as we can for testing
>  RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> --
> 2.47.2
>
>

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

[PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Alex Bennée]

When building on non-x86 we get a bunch but not all of the compilers.
Handle this in the Dockerfile by probing the arch and expanding the
list available.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
index 5aa43749ebe..16a83241270 100644
--- a/tests/docker/dockerfiles/debian-all-test-cross.docker
+++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
@@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
         bison \
         ccache \
         clang  \
+        dpkg-dev \
         flex \
+        gcc \
         git \
         libclang-rt-dev \
         ninja-build \
@@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
         python3-venv \
         python3-wheel
 
-RUN DEBIAN_FRONTEND=noninteractive eatmydata \
-        apt install -y --no-install-recommends \
-        gcc-aarch64-linux-gnu \
+# All the generally available compilers
+ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
         libc6-dev-arm64-cross \
         gcc-arm-linux-gnueabihf \
         libc6-dev-armhf-cross \
-        gcc-hppa-linux-gnu \
-        libc6-dev-hppa-cross \
-        gcc-m68k-linux-gnu \
-        libc6-dev-m68k-cross \
         gcc-mips-linux-gnu \
         libc6-dev-mips-cross \
         gcc-mips64-linux-gnuabi64 \
@@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
         libc6-dev-mips64el-cross \
         gcc-mipsel-linux-gnu \
         libc6-dev-mipsel-cross \
-        gcc-powerpc-linux-gnu \
-        libc6-dev-powerpc-cross \
-        gcc-powerpc64-linux-gnu \
-        libc6-dev-ppc64-cross \
         gcc-powerpc64le-linux-gnu \
         libc6-dev-ppc64el-cross \
         gcc-riscv64-linux-gnu \
         libc6-dev-riscv64-cross \
         gcc-s390x-linux-gnu \
-        libc6-dev-s390x-cross \
-        gcc-sparc64-linux-gnu \
-        libc6-dev-sparc64-cross && \
+        libc6-dev-s390x-cross
+
+RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
+RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
+RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
+RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
+RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
+
+RUN echo "compilers: ${AVAILABLE_COMPILERS}"
+
+RUN DEBIAN_FRONTEND=noninteractive eatmydata \
+        apt install -y --no-install-recommends \
+        ${AVAILABLE_COMPILERS} && \
         dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
 
 
-- 
2.47.2

Re: [PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> When building on non-x86 we get a bunch but not all of the compilers.
> Handle this in the Dockerfile by probing the arch and expanding the
> list available.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
>  1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
> index 5aa43749ebe..16a83241270 100644
> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
> @@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>          bison \
>          ccache \
>          clang  \
> +        dpkg-dev \
>          flex \
> +        gcc \
>          git \
>          libclang-rt-dev \
>          ninja-build \
> @@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>          python3-venv \
>          python3-wheel
>
> -RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> -        apt install -y --no-install-recommends \
> -        gcc-aarch64-linux-gnu \
> +# All the generally available compilers
> +ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
>          libc6-dev-arm64-cross \
>          gcc-arm-linux-gnueabihf \
>          libc6-dev-armhf-cross \
> -        gcc-hppa-linux-gnu \
> -        libc6-dev-hppa-cross \
> -        gcc-m68k-linux-gnu \
> -        libc6-dev-m68k-cross \
>          gcc-mips-linux-gnu \
>          libc6-dev-mips-cross \
>          gcc-mips64-linux-gnuabi64 \
> @@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>          libc6-dev-mips64el-cross \
>          gcc-mipsel-linux-gnu \
>          libc6-dev-mipsel-cross \
> -        gcc-powerpc-linux-gnu \
> -        libc6-dev-powerpc-cross \
> -        gcc-powerpc64-linux-gnu \
> -        libc6-dev-ppc64-cross \
>          gcc-powerpc64le-linux-gnu \
>          libc6-dev-ppc64el-cross \
>          gcc-riscv64-linux-gnu \
>          libc6-dev-riscv64-cross \
>          gcc-s390x-linux-gnu \
> -        libc6-dev-s390x-cross \
> -        gcc-sparc64-linux-gnu \
> -        libc6-dev-sparc64-cross && \
> +        libc6-dev-s390x-cross
> +
> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
> +
> +RUN echo "compilers: ${AVAILABLE_COMPILERS}"

Nitpick, each `RUN` command will create a new cached layer for the
container build. It makes more sense to fold them in a single `RUN`
step to avoid unnecessary layers. Does not make a big difference so
feel free to ignore.

Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>

> +
> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> +        apt install -y --no-install-recommends \
> +        ${AVAILABLE_COMPILERS} && \
>          dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
>
>
> --
> 2.47.2
>
>

Re: [PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Alex Bennée]

Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:

> On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> When building on non-x86 we get a bunch but not all of the compilers.
>> Handle this in the Dockerfile by probing the arch and expanding the
>> list available.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
>>  1 file changed, 17 insertions(+), 14 deletions(-)
>>
>> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
>> index 5aa43749ebe..16a83241270 100644
>> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
>> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
>> @@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>>          bison \
>>          ccache \
>>          clang  \
>> +        dpkg-dev \
>>          flex \
>> +        gcc \
>>          git \
>>          libclang-rt-dev \
>>          ninja-build \
>> @@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>>          python3-venv \
>>          python3-wheel
>>
>> -RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> -        apt install -y --no-install-recommends \
>> -        gcc-aarch64-linux-gnu \
>> +# All the generally available compilers
>> +ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
>>          libc6-dev-arm64-cross \
>>          gcc-arm-linux-gnueabihf \
>>          libc6-dev-armhf-cross \
>> -        gcc-hppa-linux-gnu \
>> -        libc6-dev-hppa-cross \
>> -        gcc-m68k-linux-gnu \
>> -        libc6-dev-m68k-cross \
>>          gcc-mips-linux-gnu \
>>          libc6-dev-mips-cross \
>>          gcc-mips64-linux-gnuabi64 \
>> @@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>>          libc6-dev-mips64el-cross \
>>          gcc-mipsel-linux-gnu \
>>          libc6-dev-mipsel-cross \
>> -        gcc-powerpc-linux-gnu \
>> -        libc6-dev-powerpc-cross \
>> -        gcc-powerpc64-linux-gnu \
>> -        libc6-dev-ppc64-cross \
>>          gcc-powerpc64le-linux-gnu \
>>          libc6-dev-ppc64el-cross \
>>          gcc-riscv64-linux-gnu \
>>          libc6-dev-riscv64-cross \
>>          gcc-s390x-linux-gnu \
>> -        libc6-dev-s390x-cross \
>> -        gcc-sparc64-linux-gnu \
>> -        libc6-dev-sparc64-cross && \
>> +        libc6-dev-s390x-cross
>> +
>> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
>> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
>> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
>> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
>> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
>> +
>> +RUN echo "compilers: ${AVAILABLE_COMPILERS}"
>
> Nitpick, each `RUN` command will create a new cached layer for the
> container build. It makes more sense to fold them in a single `RUN`
> step to avoid unnecessary layers. Does not make a big difference so
> feel free to ignore.

I did try to figure out how to do a multi-line shell with an env
expansion but wasn't able to get the escaping right. If you can suggest
the right runes please do ;-)

>
> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>
>> +
>> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> +        apt install -y --no-install-recommends \
>> +        ${AVAILABLE_COMPILERS} && \
>>          dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
>>
>>
>> --
>> 2.47.2
>>
>>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Manos Pitsidianakis]

On Thu, Jul 24, 2025 at 3:36 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> When building on non-x86 we get a bunch but not all of the compilers.
> >> Handle this in the Dockerfile by probing the arch and expanding the
> >> list available.
> >>
> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> ---
> >>  .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
> >>  1 file changed, 17 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> index 5aa43749ebe..16a83241270 100644
> >> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> @@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >>          bison \
> >>          ccache \
> >>          clang  \
> >> +        dpkg-dev \
> >>          flex \
> >> +        gcc \
> >>          git \
> >>          libclang-rt-dev \
> >>          ninja-build \
> >> @@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >>          python3-venv \
> >>          python3-wheel
> >>
> >> -RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> -        apt install -y --no-install-recommends \
> >> -        gcc-aarch64-linux-gnu \
> >> +# All the generally available compilers
> >> +ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
> >>          libc6-dev-arm64-cross \
> >>          gcc-arm-linux-gnueabihf \
> >>          libc6-dev-armhf-cross \
> >> -        gcc-hppa-linux-gnu \
> >> -        libc6-dev-hppa-cross \
> >> -        gcc-m68k-linux-gnu \
> >> -        libc6-dev-m68k-cross \
> >>          gcc-mips-linux-gnu \
> >>          libc6-dev-mips-cross \
> >>          gcc-mips64-linux-gnuabi64 \
> >> @@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >>          libc6-dev-mips64el-cross \
> >>          gcc-mipsel-linux-gnu \
> >>          libc6-dev-mipsel-cross \
> >> -        gcc-powerpc-linux-gnu \
> >> -        libc6-dev-powerpc-cross \
> >> -        gcc-powerpc64-linux-gnu \
> >> -        libc6-dev-ppc64-cross \
> >>          gcc-powerpc64le-linux-gnu \
> >>          libc6-dev-ppc64el-cross \
> >>          gcc-riscv64-linux-gnu \
> >>          libc6-dev-riscv64-cross \
> >>          gcc-s390x-linux-gnu \
> >> -        libc6-dev-s390x-cross \
> >> -        gcc-sparc64-linux-gnu \
> >> -        libc6-dev-sparc64-cross && \
> >> +        libc6-dev-s390x-cross
> >> +
> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
> >> +
> >> +RUN echo "compilers: ${AVAILABLE_COMPILERS}"
> >
> > Nitpick, each `RUN` command will create a new cached layer for the
> > container build. It makes more sense to fold them in a single `RUN`
> > step to avoid unnecessary layers. Does not make a big difference so
> > feel free to ignore.
>
> I did try to figure out how to do a multi-line shell with an env
> expansion but wasn't able to get the escaping right. If you can suggest
> the right runes please do ;-)

Like this?

RUN if dpkg-architecture -e amd64; then \
  export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
gcc-hppa-linux-gnu libc6-dev-hppa-cross"; \
  export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
gcc-m68k-linux-gnu libc6-dev-m68k-cross"; \
  export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; \
  export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; \
  export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; \
  fi && \
  echo "compilers: ${AVAILABLE_COMPILERS}"


>
> >
> > Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
> >
> >> +
> >> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> +        apt install -y --no-install-recommends \
> >> +        ${AVAILABLE_COMPILERS} && \
> >>          dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
> >>
> >>
> >> --
> >> 2.47.2
> >>
> >>
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

Re: [PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Alex Bennée]

Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:

> On Thu, Jul 24, 2025 at 3:36 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>>
>> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>> >>
>> >> When building on non-x86 we get a bunch but not all of the compilers.
>> >> Handle this in the Dockerfile by probing the arch and expanding the
>> >> list available.
>> >>
>> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> >> ---
>> >>  .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
>> >>  1 file changed, 17 insertions(+), 14 deletions(-)
>> >>
>> >> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
>> >> index 5aa43749ebe..16a83241270 100644
>> >> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
>> >> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
>> >> @@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> >>          bison \
>> >>          ccache \
>> >>          clang  \
>> >> +        dpkg-dev \
>> >>          flex \
>> >> +        gcc \
>> >>          git \
>> >>          libclang-rt-dev \
>> >>          ninja-build \
>> >> @@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> >>          python3-venv \
>> >>          python3-wheel
>> >>
>> >> -RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> >> -        apt install -y --no-install-recommends \
>> >> -        gcc-aarch64-linux-gnu \
>> >> +# All the generally available compilers
>> >> +ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
>> >>          libc6-dev-arm64-cross \
>> >>          gcc-arm-linux-gnueabihf \
>> >>          libc6-dev-armhf-cross \
>> >> -        gcc-hppa-linux-gnu \
>> >> -        libc6-dev-hppa-cross \
>> >> -        gcc-m68k-linux-gnu \
>> >> -        libc6-dev-m68k-cross \
>> >>          gcc-mips-linux-gnu \
>> >>          libc6-dev-mips-cross \
>> >>          gcc-mips64-linux-gnuabi64 \
>> >> @@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> >>          libc6-dev-mips64el-cross \
>> >>          gcc-mipsel-linux-gnu \
>> >>          libc6-dev-mipsel-cross \
>> >> -        gcc-powerpc-linux-gnu \
>> >> -        libc6-dev-powerpc-cross \
>> >> -        gcc-powerpc64-linux-gnu \
>> >> -        libc6-dev-ppc64-cross \
>> >>          gcc-powerpc64le-linux-gnu \
>> >>          libc6-dev-ppc64el-cross \
>> >>          gcc-riscv64-linux-gnu \
>> >>          libc6-dev-riscv64-cross \
>> >>          gcc-s390x-linux-gnu \
>> >> -        libc6-dev-s390x-cross \
>> >> -        gcc-sparc64-linux-gnu \
>> >> -        libc6-dev-sparc64-cross && \
>> >> +        libc6-dev-s390x-cross
>> >> +
>> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
>> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
>> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
>> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
>> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
>> >> +
>> >> +RUN echo "compilers: ${AVAILABLE_COMPILERS}"
>> >
>> > Nitpick, each `RUN` command will create a new cached layer for the
>> > container build. It makes more sense to fold them in a single `RUN`
>> > step to avoid unnecessary layers. Does not make a big difference so
>> > feel free to ignore.
>>
>> I did try to figure out how to do a multi-line shell with an env
>> expansion but wasn't able to get the escaping right. If you can suggest
>> the right runes please do ;-)
>
> Like this?
>
> RUN if dpkg-architecture -e amd64; then \
>   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> gcc-hppa-linux-gnu libc6-dev-hppa-cross"; \
>   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> gcc-m68k-linux-gnu libc6-dev-m68k-cross"; \
>   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; \
>   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; \
>   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; \
>   fi && \
>   echo "compilers: ${AVAILABLE_COMPILERS}"
>

Nope, the continuation has to run for all the lines of the RUN
statement.

  Processing triggers for libc-bin (2.36-9+deb12u10) ...
  --> 703d5c21c6e4
  STEP 5/18: ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu         libc6-dev-arm64-cross         gcc-arm-linux-gnueabihf         libc6-dev-armhf-cross         gcc-mips-linux-gnu         libc6-dev-mips-cross         gcc-mips64-linux-gnuabi64         libc6-dev-mips64-cross         gcc-mips64el-linux-gnuabi64         libc6-dev-mips64el-cross         gcc-mipsel-linux-gnu         libc6-dev-mipsel-cross         gcc-powerpc64le-linux-gnu         libc6-dev-ppc64el-cross         gcc-riscv64-linux-gnu         libc6-dev-riscv64-cross         gcc-s390x-linux-gnu         libc6-dev-s390x-cross
  --> e6fa99881c94
  STEP 6/18: RUN if dpkg-architecture -e amd64; then   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
  /bin/sh: 1: Syntax error: Unterminated quoted string
  Error: building at STEP "RUN if dpkg-architecture -e amd64; then   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}": while running runtime: exit status 2
  make: *** [tests/docker/Makefile.include:40: docker-image-debian-all-test-cross] Error 2

>
>>
>> >
>> > Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
>> >
>> >> +
>> >> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \
>> >> +        apt install -y --no-install-recommends \
>> >> +        ${AVAILABLE_COMPILERS} && \
>> >>          dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
>> >>
>> >>
>> >> --
>> >> 2.47.2
>> >>
>> >>
>>
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH for 10.1 13/13] tests/docker: handle host-arch selection for all-test-cross

[Manos Pitsidianakis]

On Fri, Jul 25, 2025 at 2:57 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
>
> > On Thu, Jul 24, 2025 at 3:36 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> Manos Pitsidianakis <manos.pitsidianakis@linaro.org> writes:
> >>
> >> > On Thu, Jul 24, 2025 at 2:00 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >> >>
> >> >> When building on non-x86 we get a bunch but not all of the compilers.
> >> >> Handle this in the Dockerfile by probing the arch and expanding the
> >> >> list available.
> >> >>
> >> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> >> ---
> >> >>  .../dockerfiles/debian-all-test-cross.docker  | 31 ++++++++++---------
> >> >>  1 file changed, 17 insertions(+), 14 deletions(-)
> >> >>
> >> >> diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> >> index 5aa43749ebe..16a83241270 100644
> >> >> --- a/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> >> +++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
> >> >> @@ -23,7 +23,9 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> >>          bison \
> >> >>          ccache \
> >> >>          clang  \
> >> >> +        dpkg-dev \
> >> >>          flex \
> >> >> +        gcc \
> >> >>          git \
> >> >>          libclang-rt-dev \
> >> >>          ninja-build \
> >> >> @@ -33,16 +35,11 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> >>          python3-venv \
> >> >>          python3-wheel
> >> >>
> >> >> -RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> >> -        apt install -y --no-install-recommends \
> >> >> -        gcc-aarch64-linux-gnu \
> >> >> +# All the generally available compilers
> >> >> +ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
> >> >>          libc6-dev-arm64-cross \
> >> >>          gcc-arm-linux-gnueabihf \
> >> >>          libc6-dev-armhf-cross \
> >> >> -        gcc-hppa-linux-gnu \
> >> >> -        libc6-dev-hppa-cross \
> >> >> -        gcc-m68k-linux-gnu \
> >> >> -        libc6-dev-m68k-cross \
> >> >>          gcc-mips-linux-gnu \
> >> >>          libc6-dev-mips-cross \
> >> >>          gcc-mips64-linux-gnuabi64 \
> >> >> @@ -51,18 +48,24 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> >>          libc6-dev-mips64el-cross \
> >> >>          gcc-mipsel-linux-gnu \
> >> >>          libc6-dev-mipsel-cross \
> >> >> -        gcc-powerpc-linux-gnu \
> >> >> -        libc6-dev-powerpc-cross \
> >> >> -        gcc-powerpc64-linux-gnu \
> >> >> -        libc6-dev-ppc64-cross \
> >> >>          gcc-powerpc64le-linux-gnu \
> >> >>          libc6-dev-ppc64el-cross \
> >> >>          gcc-riscv64-linux-gnu \
> >> >>          libc6-dev-riscv64-cross \
> >> >>          gcc-s390x-linux-gnu \
> >> >> -        libc6-dev-s390x-cross \
> >> >> -        gcc-sparc64-linux-gnu \
> >> >> -        libc6-dev-sparc64-cross && \
> >> >> +        libc6-dev-s390x-cross
> >> >> +
> >> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross"; fi
> >> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross"; fi
> >> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; fi
> >> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; fi
> >> >> +RUN if dpkg-architecture -e amd64; then export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS} gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; fi
> >> >> +
> >> >> +RUN echo "compilers: ${AVAILABLE_COMPILERS}"
> >> >
> >> > Nitpick, each `RUN` command will create a new cached layer for the
> >> > container build. It makes more sense to fold them in a single `RUN`
> >> > step to avoid unnecessary layers. Does not make a big difference so
> >> > feel free to ignore.
> >>
> >> I did try to figure out how to do a multi-line shell with an env
> >> expansion but wasn't able to get the escaping right. If you can suggest
> >> the right runes please do ;-)
> >
> > Like this?
> >
> > RUN if dpkg-architecture -e amd64; then \
> >   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> > gcc-hppa-linux-gnu libc6-dev-hppa-cross"; \
> >   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> > gcc-m68k-linux-gnu libc6-dev-m68k-cross"; \
> >   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> > gcc-powerpc-linux-gnu libc6-dev-powerpc-cross"; \
> >   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> > gcc-powerpc64-linux-gnu libc6-dev-ppc64-cross"; \
> >   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
> > gcc-sparc64-linux-gnu libc6-dev-sparc64-cross"; \
> >   fi && \
> >   echo "compilers: ${AVAILABLE_COMPILERS}"
> >
>
> Nope, the continuation has to run for all the lines of the RUN
> statement.

Sorry, it seems Gmail textwrapped the lines. The ones without
continuation should be merged with the following one.


>
>   Processing triggers for libc-bin (2.36-9+deb12u10) ...
>   --> 703d5c21c6e4
>   STEP 5/18: ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu         libc6-dev-arm64-cross         gcc-arm-linux-gnueabihf         libc6-dev-armhf-cross         gcc-mips-linux-gnu         libc6-dev-mips-cross         gcc-mips64-linux-gnuabi64         libc6-dev-mips64-cross         gcc-mips64el-linux-gnuabi64         libc6-dev-mips64el-cross         gcc-mipsel-linux-gnu         libc6-dev-mipsel-cross         gcc-powerpc64le-linux-gnu         libc6-dev-ppc64el-cross         gcc-riscv64-linux-gnu         libc6-dev-riscv64-cross         gcc-s390x-linux-gnu         libc6-dev-s390x-cross
>   --> e6fa99881c94
>   STEP 6/18: RUN if dpkg-architecture -e amd64; then   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}
>   /bin/sh: 1: Syntax error: Unterminated quoted string
>   Error: building at STEP "RUN if dpkg-architecture -e amd64; then   export AVAILABLE_COMPILERS="${AVAILABLE_COMPILERS}": while running runtime: exit status 2
>   make: *** [tests/docker/Makefile.include:40: docker-image-debian-all-test-cross] Error 2
>
> >
> >>
> >> >
> >> > Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
> >> >
> >> >> +
> >> >> +RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> >> >> +        apt install -y --no-install-recommends \
> >> >> +        ${AVAILABLE_COMPILERS} && \
> >> >>          dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
> >> >>
> >> >>
> >> >> --
> >> >> 2.47.2
> >> >>
> >> >>
> >>
> >> --
> >> Alex Bennée
> >> Virtualisation Tech Lead @ Linaro
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro