[PATCH v2 00/16] testing/next: various updates (MacOS, docker, gitlab)

[PATCH v2 00/16] testing/next: various updates (MacOS, docker, gitlab)

[Alex Bennée]

These patches are mostly dealing with the loss of the CirrusCI MacOS
images by porting to gitlab. I've had to fight a bit with the build
system to deal with the way MacOS has signed and unsigned versions of
QEMU. In the end I couldn't get the dependencies to work for check-tcg
so I've just called the check-tcg test runners directly.

There is also a fix for getting watchpoints working so we can have the
basic TCG gdb tests.

I've also included Phil's docker series which is already reviewed.

The following still need review:

  gitlab: add MacOS 26 job on gitlab runner
  gitlab: add initial MacOS 15 on gitlab runner
  ci: drop cirrus MacOS build
  accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
  tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
  tests/Makefile.include: fix typo in comment
  Makefile: include tests/Makefile.include before ninja calculation

Alex.

Alex Bennée (9):
  Makefile: include tests/Makefile.include before ninja calculation
  tests/Makefile.include: fix typo in comment
  tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
  accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
  ci: drop cirrus MacOS build
  gitlab: add initial MacOS 15 on gitlab runner
  gitlab: add MacOS 26 job on gitlab runner
  gitlab: update issue template for binary test cases
  MAINTAINERS: add a section for AI agents

Philippe Mathieu-Daudé (7):
  MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
  MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch
    section
  MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
  MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
  MAINTAINERS: Cover python.docker with Python library section
  docker: Remove LegacyKeyValueFormat warnings in non-generated files
  docker: Remove LegacyKeyValueFormat warnings in generated files

 MAINTAINERS                                   | 12 +++-
 Makefile                                      |  4 +-
 accel/tcg/tb-maint.c                          | 43 ++++++-------
 tests/lcitool/refresh                         | 24 +++++--
 tests/docker/dockerfiles/alpine.docker        |  2 +-
 tests/docker/dockerfiles/centos9.docker       |  2 +-
 .../dockerfiles/debian-all-test-cross.docker  | 10 +--
 .../dockerfiles/debian-amd64-cross.docker     |  2 +-
 .../dockerfiles/debian-arm64-cross.docker     |  2 +-
 .../dockerfiles/debian-armhf-cross.docker     |  2 +-
 .../dockerfiles/debian-hexagon-cross.docker   | 14 ++---
 .../dockerfiles/debian-i686-cross.docker      |  2 +-
 .../dockerfiles/debian-loongarch-cross.docker | 10 +--
 .../dockerfiles/debian-mips64el-cross.docker  |  2 +-
 .../dockerfiles/debian-mipsel-cross.docker    |  2 +-
 .../dockerfiles/debian-ppc64el-cross.docker   |  2 +-
 .../dockerfiles/debian-riscv64-cross.docker   |  2 +-
 .../dockerfiles/debian-s390x-cross.docker     |  2 +-
 .../dockerfiles/debian-tricore-cross.docker   |  6 +-
 .../dockerfiles/debian-xtensa-cross.docker    |  8 +--
 tests/docker/dockerfiles/debian.docker        |  2 +-
 .../dockerfiles/fedora-rust-nightly.docker    |  2 +-
 .../dockerfiles/fedora-win64-cross.docker     |  2 +-
 tests/docker/dockerfiles/fedora.docker        |  2 +-
 tests/docker/dockerfiles/opensuse-leap.docker |  2 +-
 tests/docker/dockerfiles/python.docker        |  5 +-
 .gitlab-ci.d/cirrus.yml                       | 14 -----
 .gitlab-ci.d/{cirrus => }/macos-14.vars       |  0
 .gitlab-ci.d/macos.yml                        | 63 +++++++++++++++++++
 .gitlab-ci.d/qemu-project.yml                 |  1 +
 .gitlab/issue_templates/bug.md                |  4 ++
 scripts/coverity-scan/coverity-scan.docker    | 12 ++--
 scripts/git.orderfile                         |  4 ++
 tests/Makefile.include                        |  8 ++-
 34 files changed, 179 insertions(+), 95 deletions(-)
 rename .gitlab-ci.d/{cirrus => }/macos-14.vars (100%)
 create mode 100644 .gitlab-ci.d/macos.yml

-- 
2.47.3

[PATCH v2 01/16] Makefile: include tests/Makefile.include before ninja calculation

[Alex Bennée]

As the tests Makefile sets .ninja-goals we need it to be included
before we do the calculations in the main Makefile.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 54547a37b1a..829c51e364c 100644
--- a/Makefile
+++ b/Makefile
@@ -45,6 +45,8 @@ include config-host.mak
 include Makefile.prereqs
 Makefile.prereqs: config-host.mak
 
+include $(SRC_PATH)/tests/Makefile.include
+
 # 0. ensure the build tree is okay
 
 # Check that we're not trying to do an out-of-tree build from
@@ -180,8 +182,6 @@ endif # config-host.mak does not exist
 
 SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory --quiet)
 
-include $(SRC_PATH)/tests/Makefile.include
-
 all: recurse-all
 
 SUBDIR_RULES=$(foreach t, all clean distclean, $(addsuffix /$(t), $(SUBDIRS)))
-- 
2.47.3

Re: [PATCH v2 01/16] Makefile: include tests/Makefile.include before ninja calculation

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> As the tests Makefile sets .ninja-goals we need it to be included
> before we do the calculations in the main Makefile.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

[PATCH v2 02/16] tests/Makefile.include: fix typo in comment

[Alex Bennée]

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/Makefile.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index f257288194d..ce6a0dccaf4 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -41,7 +41,7 @@ SPEED = quick
 
 
 # TCG_TESTS_WITH_COMPILERS represents the test targets we have cross compiler
-# support for, CONFIGURED_TEST_TARGETS it what meson has finally
+# support for, CONFIGURED_TCG_TARGETS it what meson has finally
 # configured having rejected stuff we can't build.
 CONFIGURED_TCG_TARGETS=$(patsubst %-config-target.h, %, $(wildcard *-config-target.h))
 
-- 
2.47.3

Re: [PATCH v2 02/16] tests/Makefile.include: fix typo in comment

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/Makefile.include | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

[PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Explicitly set the appropriate QEMU binary as a dependency so we can
ensure they get built. This is especially important for MacOS which
otherwise only builds the unsigned binaries on a normal "make all"
run.

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

diff --git a/tests/Makefile.include b/tests/Makefile.include
index ce6a0dccaf4..cf6f9e68245 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -57,6 +57,12 @@ RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(TCG_TESTS_TARGETS))
 $(foreach TARGET,$(TCG_TESTS_TARGETS), \
         $(eval $(BUILD_DIR)/tests/tcg/config-$(TARGET).mak: config-host.mak))
 
+# $1 = the stem (e.g., arm-softmmu or x86_64-linux-user)
+get-qemu-bin = $(if $(findstring softmmu,$1),qemu-system-$(subst -softmmu,,$1),qemu-$(subst -linux-user,,$1))
+
+$(foreach TARGET,$(TCG_TESTS_TARGETS), \
+        $(eval .ninja-goals.run-tcg-tests-$(TARGET) += $(call get-qemu-bin,$(TARGET))))
+
 .PHONY: $(TCG_TESTS_TARGETS:%=build-tcg-tests-%)
 $(TCG_TESTS_TARGETS:%=build-tcg-tests-%): build-tcg-tests-%: $(BUILD_DIR)/tests/tcg/config-%.mak
 	$(call quiet-command, \
-- 
2.47.3

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> Explicitly set the appropriate QEMU binary as a dependency so we can
> ensure they get built. This is especially important for MacOS which
> otherwise only builds the unsigned binaries on a normal "make all"
> run.
>

I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
unsigned binaries are plenty for it.

Which other binary is this building that is not built by default?

In general, if something is not included in "all" target, let's make
sure it's included there (meson.build?) instead of adding a workaround
here. Not only tests benefit this, but anyone doing a build on a
platform that might have optional binaries not built by default.

It's totally ok to build all binaries (even for other targets than one
tested), people have configure --target-list to restrict what is
globally built. Better to catch something broken elsewhere instead of
"oh sorry, my custom test command didn't build this at the time".

> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/Makefile.include | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/Makefile.include b/tests/Makefile.include
> index ce6a0dccaf4..cf6f9e68245 100644
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -57,6 +57,12 @@ RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(TCG_TESTS_TARGETS))
>  $(foreach TARGET,$(TCG_TESTS_TARGETS), \
>          $(eval $(BUILD_DIR)/tests/tcg/config-$(TARGET).mak: config-host.mak))
>  
> +# $1 = the stem (e.g., arm-softmmu or x86_64-linux-user)
> +get-qemu-bin = $(if $(findstring softmmu,$1),qemu-system-$(subst -softmmu,,$1),qemu-$(subst -linux-user,,$1))
> +
> +$(foreach TARGET,$(TCG_TESTS_TARGETS), \
> +        $(eval .ninja-goals.run-tcg-tests-$(TARGET) += $(call get-qemu-bin,$(TARGET))))
> +
>  .PHONY: $(TCG_TESTS_TARGETS:%=build-tcg-tests-%)
>  $(TCG_TESTS_TARGETS:%=build-tcg-tests-%): build-tcg-tests-%: $(BUILD_DIR)/tests/tcg/config-%.mak
>  	$(call quiet-command, \

Regards,
Pierrick

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>> Explicitly set the appropriate QEMU binary as a dependency so we can
>> ensure they get built. This is especially important for MacOS which
>> otherwise only builds the unsigned binaries on a normal "make all"
>> run.
>>
>
> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
> unsigned binaries are plenty for it.
>
> Which other binary is this building that is not built by default?
>
> In general, if something is not included in "all" target, let's make
> sure it's included there (meson.build?) instead of adding a workaround
> here. Not only tests benefit this, but anyone doing a build on a
> platform that might have optional binaries not built by default.

If you have a suggestion on how to make that work I'm all ears.

>
> It's totally ok to build all binaries (even for other targets than one
> tested), people have configure --target-list to restrict what is
> globally built. Better to catch something broken elsewhere instead of
> "oh sorry, my custom test command didn't build this at the time".
>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  tests/Makefile.include | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/tests/Makefile.include b/tests/Makefile.include
>> index ce6a0dccaf4..cf6f9e68245 100644
>> --- a/tests/Makefile.include
>> +++ b/tests/Makefile.include
>> @@ -57,6 +57,12 @@ RUN_TCG_TARGET_RULES=$(patsubst %,run-tcg-tests-%, $(TCG_TESTS_TARGETS))
>>  $(foreach TARGET,$(TCG_TESTS_TARGETS), \
>>          $(eval $(BUILD_DIR)/tests/tcg/config-$(TARGET).mak: config-host.mak))
>>  
>> +# $1 = the stem (e.g., arm-softmmu or x86_64-linux-user)
>> +get-qemu-bin = $(if $(findstring softmmu,$1),qemu-system-$(subst -softmmu,,$1),qemu-$(subst -linux-user,,$1))
>> +
>> +$(foreach TARGET,$(TCG_TESTS_TARGETS), \
>> +        $(eval .ninja-goals.run-tcg-tests-$(TARGET) += $(call get-qemu-bin,$(TARGET))))
>> +
>>  .PHONY: $(TCG_TESTS_TARGETS:%=build-tcg-tests-%)
>>  $(TCG_TESTS_TARGETS:%=build-tcg-tests-%): build-tcg-tests-%: $(BUILD_DIR)/tests/tcg/config-%.mak
>>  	$(call quiet-command, \
>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/22/2026 12:02 PM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>> ensure they get built. This is especially important for MacOS which
>>> otherwise only builds the unsigned binaries on a normal "make all"
>>> run.
>>>
>>
>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>> unsigned binaries are plenty for it.
>>
>> Which other binary is this building that is not built by default?
>>
>> In general, if something is not included in "all" target, let's make
>> sure it's included there (meson.build?) instead of adding a workaround
>> here. Not only tests benefit this, but anyone doing a build on a
>> platform that might have optional binaries not built by default.
> 
> If you have a suggestion on how to make that work I'm all ears.
>

I would be happy to help, but I don't understand what the goal is. I
have three questions that should help to provide a suggestion.

Which exact test command do you run?

```
Explicitly set the appropriate QEMU binary as a dependency so we can
ensure they get built.
```
Aren't they built by all?
It seems to be a dependency, at least for check-tcg:
.ninja-goals.check-tcg = all test-plugins

```
This is especially important for MacOS which otherwise only builds the
unsigned binaries on a normal "make all" run.
```
Why do you need signed binaries for testing on MacOS (hvf?)?
Regards,
Pierrick

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>> ensure they get built. This is especially important for MacOS which
>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>> run.
>>>>
>>>
>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>> unsigned binaries are plenty for it.
>>>
>>> Which other binary is this building that is not built by default?
>>>
>>> In general, if something is not included in "all" target, let's make
>>> sure it's included there (meson.build?) instead of adding a workaround
>>> here. Not only tests benefit this, but anyone doing a build on a
>>> platform that might have optional binaries not built by default.
>> 
>> If you have a suggestion on how to make that work I'm all ears.
>>
>
> I would be happy to help, but I don't understand what the goal is. I
> have three questions that should help to provide a suggestion.
>
> Which exact test command do you run?

make check-tcg

>
> ```
> Explicitly set the appropriate QEMU binary as a dependency so we can
> ensure they get built.
> ```
> Aren't they built by all?

Apparently not.

> It seems to be a dependency, at least for check-tcg:
> .ninja-goals.check-tcg = all test-plugins
>
> ```
> This is especially important for MacOS which otherwise only builds the
> unsigned binaries on a normal "make all" run.
> ```
> Why do you need signed binaries for testing on MacOS (hvf?)?

In a previous iteration I made configure spit out the unsigned binaries
to config-target.mak but the request was to fix the dependencies
instead.

It all works on Linux so I'm not sure why MacOS is being so weird
because the meson emulators target mechanism should be the same.

> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/23/2026 1:56 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>> ensure they get built. This is especially important for MacOS which
>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>> run.
>>>>>
>>>>
>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>> unsigned binaries are plenty for it.
>>>>
>>>> Which other binary is this building that is not built by default?
>>>>
>>>> In general, if something is not included in "all" target, let's make
>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>> platform that might have optional binaries not built by default.
>>>
>>> If you have a suggestion on how to make that work I'm all ears.
>>>
>>
>> I would be happy to help, but I don't understand what the goal is. I
>> have three questions that should help to provide a suggestion.
>>
>> Which exact test command do you run?
> 
> make check-tcg
> 
>>
>> ```
>> Explicitly set the appropriate QEMU binary as a dependency so we can
>> ensure they get built.
>> ```
>> Aren't they built by all?
> 
> Apparently not.
> 
>> It seems to be a dependency, at least for check-tcg:
>> .ninja-goals.check-tcg = all test-plugins
>>
>> ```
>> This is especially important for MacOS which otherwise only builds the
>> unsigned binaries on a normal "make all" run.
>> ```
>> Why do you need signed binaries for testing on MacOS (hvf?)?
> 
> In a previous iteration I made configure spit out the unsigned binaries
> to config-target.mak but the request was to fix the dependencies
> instead.
> 
> It all works on Linux so I'm not sure why MacOS is being so weird
> because the meson emulators target mechanism should be the same.
>

Just tried now, and it does not work on Linux neither (make check-tcg
does not build any target beyond tests). Maybe you forgot to clean your
folder?

>> Regards,
>> Pierrick
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>
>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>> run.
>>>>>>
>>>>>
>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>> unsigned binaries are plenty for it.
>>>>>
>>>>> Which other binary is this building that is not built by default?
>>>>>
>>>>> In general, if something is not included in "all" target, let's make
>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>> platform that might have optional binaries not built by default.
>>>>
>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>
>>>
>>> I would be happy to help, but I don't understand what the goal is. I
>>> have three questions that should help to provide a suggestion.
>>>
>>> Which exact test command do you run?
>>
>> make check-tcg
>>
>>>
>>> ```
>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>> ensure they get built.
>>> ```
>>> Aren't they built by all?
>>
>> Apparently not.
>>
>>> It seems to be a dependency, at least for check-tcg:
>>> .ninja-goals.check-tcg = all test-plugins
>>>
>>> ```
>>> This is especially important for MacOS which otherwise only builds the
>>> unsigned binaries on a normal "make all" run.
>>> ```
>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>
>> In a previous iteration I made configure spit out the unsigned binaries
>> to config-target.mak but the request was to fix the dependencies
>> instead.
>>
>> It all works on Linux so I'm not sure why MacOS is being so weird
>> because the meson emulators target mechanism should be the same.
>>
> 
> Just tried now, and it does not work on Linux neither (make check-tcg
> does not build any target beyond tests). Maybe you forgot to clean your
> folder?
>

The root issue is that tests/Makefile.include is included *after*
evaluation of ninja-targets in main Makefile. Thus,
.ninja-goals.check-tcg is ignored.

The fix is to move ninja-targets evaluation to the end of main Makefile,
which introduce the expected dependency for check-tcg to "all
test-plugins" targets.

You can replace current patch with the one attached to this email.

Regards,
Pierrick

[-- Attachment #2: 0001-Makefile-move-ninja-targets-evaluation-to-end-of-fil.patch --]
[-- Type: text/plain, Size: 4822 bytes --]

From ffc418f1ade427e3ab4648d97af37888f424baa7 Mon Sep 17 00:00:00 2001
From: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Date: Mon, 25 May 2026 10:09:56 -0700
Subject: [PATCH] Makefile: move ninja-targets evaluation to end of file

Alex found that make check-tcg was not correctly building qemu binaries.
The problem was that ./tests/Makefile.include is included *after*
evaluating ninja-targets. Thus, .ninja-goals.check-tcg was ignored.

To fix this and avoid mistakes in the future, just move the
ninja-targets evaluation at end of main Makefile.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 Makefile | 88 +++++++++++++++++++++++++++++---------------------------
 1 file changed, 45 insertions(+), 43 deletions(-)

diff --git a/Makefile b/Makefile
index 54547a37b1a..5e00bc090fc 100644
--- a/Makefile
+++ b/Makefile
@@ -135,49 +135,6 @@ $(SRC_PATH)/scripts/meson-buildoptions.sh: $(SRC_PATH)/meson_options.txt $(SRC_P
 	  scripts/meson-buildoptions.py > $@.tmp && mv $@.tmp $@
 endif
 
-# 4. Rules to bridge to other makefiles
-
-ifneq ($(NINJA),)
-# Filter out long options to avoid flags like --no-print-directory which
-# may result in false positive match for MAKE.n
-MAKE.n = $(findstring n,$(firstword $(filter-out --%,$(MAKEFLAGS))))
-MAKE.k = $(findstring k,$(firstword $(filter-out --%,$(MAKEFLAGS))))
-MAKE.q = $(findstring q,$(firstword $(filter-out --%,$(MAKEFLAGS))))
-MAKE.nq = $(if $(word 2, $(MAKE.n) $(MAKE.q)),nq)
-NINJAFLAGS = \
-        $(if $V,-v) \
-        $(if $(MAKE.n), -n) \
-        $(if $(MAKE.k), -k0) \
-        $(filter-out -j, \
-          $(or $(filter -l% -j%, $(MAKEFLAGS)), \
-               $(if $(filter --jobserver-auth=%, $(MAKEFLAGS)),, -j1))) \
-        -d keepdepfile
-ninja-cmd-goals += $(or $(MAKECMDGOALS), all)
-ninja-cmd-goals += $(foreach g, $(MAKECMDGOALS), $(.ninja-goals.$g))
-
-makefile-targets := build.ninja ctags TAGS cscope dist clean
-# "ninja -t targets" also lists all prerequisites.  If build system
-# files are marked as PHONY, however, Make will always try to execute
-# "ninja build.ninja".
-ninja-targets := $(filter-out $(build-files) $(makefile-targets), $(ninja-targets))
-.PHONY: $(ninja-targets) run-ninja
-$(ninja-targets): run-ninja
-
-# Use "| cat" to give Ninja a more "make-y" output.  Use "+" to bypass the
-# --output-sync line.
-run-ninja: config-host.mak
-ifneq ($(filter $(ninja-targets), $(ninja-cmd-goals)),)
-	+$(if $(MAKE.nq),@:,$(quiet-@)$(NINJA) $(NINJAFLAGS) \
-	   $(sort $(filter $(ninja-targets), $(ninja-cmd-goals))) | cat)
-endif
-endif
-
-else # config-host.mak does not exist
-ifneq ($(filter-out $(UNCHECKED_GOALS),$(MAKECMDGOALS)),$(if $(MAKECMDGOALS),,fail))
-$(error Please call configure before running make)
-endif
-endif # config-host.mak does not exist
-
 SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory --quiet)
 
 include $(SRC_PATH)/tests/Makefile.include
@@ -337,3 +294,48 @@ endif
 
 print-%:
 	@echo '$*=$($*)'
+
+######################################################################
+
+# 4. Rules to bridge to other makefiles
+
+ifneq ($(NINJA),)
+# Filter out long options to avoid flags like --no-print-directory which
+# may result in false positive match for MAKE.n
+MAKE.n = $(findstring n,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+MAKE.k = $(findstring k,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+MAKE.q = $(findstring q,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+MAKE.nq = $(if $(word 2, $(MAKE.n) $(MAKE.q)),nq)
+NINJAFLAGS = \
+        $(if $V,-v) \
+        $(if $(MAKE.n), -n) \
+        $(if $(MAKE.k), -k0) \
+        $(filter-out -j, \
+          $(or $(filter -l% -j%, $(MAKEFLAGS)), \
+               $(if $(filter --jobserver-auth=%, $(MAKEFLAGS)),, -j1))) \
+        -d keepdepfile
+ninja-cmd-goals += $(or $(MAKECMDGOALS), all)
+ninja-cmd-goals += $(foreach g, $(MAKECMDGOALS), $(.ninja-goals.$g))
+
+makefile-targets := build.ninja ctags TAGS cscope dist clean
+# "ninja -t targets" also lists all prerequisites.  If build system
+# files are marked as PHONY, however, Make will always try to execute
+# "ninja build.ninja".
+ninja-targets := $(filter-out $(build-files) $(makefile-targets), $(ninja-targets))
+.PHONY: $(ninja-targets) run-ninja
+$(ninja-targets): run-ninja
+
+# Use "| cat" to give Ninja a more "make-y" output.  Use "+" to bypass the
+# --output-sync line.
+run-ninja: config-host.mak
+ifneq ($(filter $(ninja-targets), $(ninja-cmd-goals)),)
+	+$(if $(MAKE.nq),@:,$(quiet-@)$(NINJA) $(NINJAFLAGS) \
+	   $(sort $(filter $(ninja-targets), $(ninja-cmd-goals))) | cat)
+endif
+endif
+
+else # config-host.mak does not exist
+ifneq ($(filter-out $(UNCHECKED_GOALS),$(MAKECMDGOALS)),$(if $(MAKECMDGOALS),,fail))
+$(error Please call configure before running make)
+endif
+endif # config-host.mak does not exist
-- 
2.43.0

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>> run.
>>>>>>>
>>>>>>
>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>> unsigned binaries are plenty for it.
>>>>>>
>>>>>> Which other binary is this building that is not built by default?
>>>>>>
>>>>>> In general, if something is not included in "all" target, let's make
>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>> platform that might have optional binaries not built by default.
>>>>>
>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>
>>>>
>>>> I would be happy to help, but I don't understand what the goal is. I
>>>> have three questions that should help to provide a suggestion.
>>>>
>>>> Which exact test command do you run?
>>>
>>> make check-tcg
>>>
>>>>
>>>> ```
>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>> ensure they get built.
>>>> ```
>>>> Aren't they built by all?
>>>
>>> Apparently not.
>>>
>>>> It seems to be a dependency, at least for check-tcg:
>>>> .ninja-goals.check-tcg = all test-plugins
>>>>
>>>> ```
>>>> This is especially important for MacOS which otherwise only builds the
>>>> unsigned binaries on a normal "make all" run.
>>>> ```
>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>
>>> In a previous iteration I made configure spit out the unsigned binaries
>>> to config-target.mak but the request was to fix the dependencies
>>> instead.
>>>
>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>> because the meson emulators target mechanism should be the same.
>>>
>> 
>> Just tried now, and it does not work on Linux neither (make check-tcg
>> does not build any target beyond tests). Maybe you forgot to clean your
>> folder?
>>
>
> The root issue is that tests/Makefile.include is included *after*
> evaluation of ninja-targets in main Makefile. Thus,
> .ninja-goals.check-tcg is ignored.

So this replaces patch 1/16 - I think we have a circular dependency here.

>
> The fix is to move ninja-targets evaluation to the end of main Makefile,
> which introduce the expected dependency for check-tcg to "all
> test-plugins" targets.
>
> You can replace current patch with the one attached to this email.
>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/25/2026 11:43 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>
>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>> run.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>> unsigned binaries are plenty for it.
>>>>>>>
>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>
>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>> platform that might have optional binaries not built by default.
>>>>>>
>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>
>>>>>
>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>> have three questions that should help to provide a suggestion.
>>>>>
>>>>> Which exact test command do you run?
>>>>
>>>> make check-tcg
>>>>
>>>>>
>>>>> ```
>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>> ensure they get built.
>>>>> ```
>>>>> Aren't they built by all?
>>>>
>>>> Apparently not.
>>>>
>>>>> It seems to be a dependency, at least for check-tcg:
>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>
>>>>> ```
>>>>> This is especially important for MacOS which otherwise only builds the
>>>>> unsigned binaries on a normal "make all" run.
>>>>> ```
>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>
>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>> to config-target.mak but the request was to fix the dependencies
>>>> instead.
>>>>
>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>> because the meson emulators target mechanism should be the same.
>>>>
>>>
>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>> does not build any target beyond tests). Maybe you forgot to clean your
>>> folder?
>>>
>>
>> The root issue is that tests/Makefile.include is included *after*
>> evaluation of ninja-targets in main Makefile. Thus,
>> .ninja-goals.check-tcg is ignored.
> 
> So this replaces patch 1/16 - I think we have a circular dependency here.
>

Indeed, I didn't notice the duplication. While it solves things under
Linux, it doesn't trigger any build on MacOS, which is what you observed
also. I wonder if it's a gmake vs whatever-make difference.

Another solution that seems ok on both platforms is to use (harmful)
recursive make:

 .PHONY: check-tcg
-.ninja-goals.check-tcg = all test-plugins
-check-tcg: $(RUN_TCG_TARGET_RULES)
+check-tcg:
+ $(MAKE) all test-plugins
+ $(MAKE) $(RUN_TCG_TARGET_RULES)

 .PHONY: clean-tcg
 clean-tcg: $(CLEAN_TCG_TARGET_RULES)

Or maybe just leave it as it is? Doc already mentions build should be
done before running any test to avoid missing binaries.
Hopefully we'll completely move tcg tests to meson one day, so there is
no need to deal with make idiosyncrasy anymore.

>>
>> The fix is to move ninja-targets evaluation to the end of main Makefile,
>> which introduce the expected dependency for check-tcg to "all
>> test-plugins" targets.
>>
>> You can replace current patch with the one attached to this email.
>>
>> Regards,
>> Pierrick
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>
>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>>> run.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>>> unsigned binaries are plenty for it.
>>>>>>>>
>>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>>
>>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>>> platform that might have optional binaries not built by default.
>>>>>>>
>>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>>
>>>>>>
>>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>>> have three questions that should help to provide a suggestion.
>>>>>>
>>>>>> Which exact test command do you run?
>>>>>
>>>>> make check-tcg
>>>>>
>>>>>>
>>>>>> ```
>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>> ensure they get built.
>>>>>> ```
>>>>>> Aren't they built by all?
>>>>>
>>>>> Apparently not.
>>>>>
>>>>>> It seems to be a dependency, at least for check-tcg:
>>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>>
>>>>>> ```
>>>>>> This is especially important for MacOS which otherwise only builds the
>>>>>> unsigned binaries on a normal "make all" run.
>>>>>> ```
>>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>>
>>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>>> to config-target.mak but the request was to fix the dependencies
>>>>> instead.
>>>>>
>>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>>> because the meson emulators target mechanism should be the same.
>>>>>
>>>>
>>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>>> does not build any target beyond tests). Maybe you forgot to clean your
>>>> folder?
>>>>
>>>
>>> The root issue is that tests/Makefile.include is included *after*
>>> evaluation of ninja-targets in main Makefile. Thus,
>>> .ninja-goals.check-tcg is ignored.
>> 
>> So this replaces patch 1/16 - I think we have a circular dependency here.
>>
>
> Indeed, I didn't notice the duplication. While it solves things under
> Linux, it doesn't trigger any build on MacOS, which is what you observed
> also. I wonder if it's a gmake vs whatever-make difference.
>
> Another solution that seems ok on both platforms is to use (harmful)
> recursive make:
>
>  .PHONY: check-tcg
> -.ninja-goals.check-tcg = all test-plugins
> -check-tcg: $(RUN_TCG_TARGET_RULES)
> +check-tcg:
> + $(MAKE) all test-plugins
> + $(MAKE) $(RUN_TCG_TARGET_RULES)
>
>  .PHONY: clean-tcg
>  clean-tcg: $(CLEAN_TCG_TARGET_RULES)
>
> Or maybe just leave it as it is? Doc already mentions build should be
> done before running any test to avoid missing binaries.
> Hopefully we'll completely move tcg tests to meson one day, so there is
> no need to deal with make idiosyncrasy anymore.

The blocker for that to happen would be meson knowing about anything
else than the host compiler and singular cross compiler.

>
>>>
>>> The fix is to move ninja-targets evaluation to the end of main Makefile,
>>> which introduce the expected dependency for check-tcg to "all
>>> test-plugins" targets.
>>>
>>> You can replace current patch with the one attached to this email.
>>>
>>> Regards,
>>> Pierrick
>> 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/26/2026 3:47 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>
>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>
>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>>>> run.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>>>> unsigned binaries are plenty for it.
>>>>>>>>>
>>>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>>>
>>>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>>>> platform that might have optional binaries not built by default.
>>>>>>>>
>>>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>>>
>>>>>>>
>>>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>>>> have three questions that should help to provide a suggestion.
>>>>>>>
>>>>>>> Which exact test command do you run?
>>>>>>
>>>>>> make check-tcg
>>>>>>
>>>>>>>
>>>>>>> ```
>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>> ensure they get built.
>>>>>>> ```
>>>>>>> Aren't they built by all?
>>>>>>
>>>>>> Apparently not.
>>>>>>
>>>>>>> It seems to be a dependency, at least for check-tcg:
>>>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>>>
>>>>>>> ```
>>>>>>> This is especially important for MacOS which otherwise only builds the
>>>>>>> unsigned binaries on a normal "make all" run.
>>>>>>> ```
>>>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>>>
>>>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>>>> to config-target.mak but the request was to fix the dependencies
>>>>>> instead.
>>>>>>
>>>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>>>> because the meson emulators target mechanism should be the same.
>>>>>>
>>>>>
>>>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>>>> does not build any target beyond tests). Maybe you forgot to clean your
>>>>> folder?
>>>>>
>>>>
>>>> The root issue is that tests/Makefile.include is included *after*
>>>> evaluation of ninja-targets in main Makefile. Thus,
>>>> .ninja-goals.check-tcg is ignored.
>>>
>>> So this replaces patch 1/16 - I think we have a circular dependency here.
>>>
>>
>> Indeed, I didn't notice the duplication. While it solves things under
>> Linux, it doesn't trigger any build on MacOS, which is what you observed
>> also. I wonder if it's a gmake vs whatever-make difference.
>>
>> Another solution that seems ok on both platforms is to use (harmful)
>> recursive make:
>>
>>  .PHONY: check-tcg
>> -.ninja-goals.check-tcg = all test-plugins
>> -check-tcg: $(RUN_TCG_TARGET_RULES)
>> +check-tcg:
>> + $(MAKE) all test-plugins
>> + $(MAKE) $(RUN_TCG_TARGET_RULES)
>>
>>  .PHONY: clean-tcg
>>  clean-tcg: $(CLEAN_TCG_TARGET_RULES)
>>
>> Or maybe just leave it as it is? Doc already mentions build should be
>> done before running any test to avoid missing binaries.
>> Hopefully we'll completely move tcg tests to meson one day, so there is
>> no need to deal with make idiosyncrasy anymore.
> 
> The blocker for that to happen would be meson knowing about anything
> else than the host compiler and singular cross compiler.
>

Meson indeed supports a single compiler + cross compiler at a time.
However, you can directly generate cross binaries using a custom_target
or a generator object. This way, meson would generate programs without
having to know it's a C compiler. Since all files are single source,
it's not a problem, since we don't need to declare them.
Generators have the advantage of being less verbose (you declare only
once how to use them) than custom target when used several times.

https://mesonbuild.com/Reference-manual_functions_generator.html
https://mesonbuild.com/Generating-sources.html#using-generator

See a full working example below:
```
$ cat meson.build
project('cross_compile_tests', 'c')

cc_aarch64 = generator(
               find_program('aarch64-linux-gnu-gcc'),
               arguments: ['@INPUT@', '-o', '@OUTPUT@', '@EXTRA_ARGS@'],
               output: '@BASENAME@')

tests = [
  cc_aarch64.process('test.c'),
  cc_aarch64.process('test2.c', extra_args: '-lpthread')
]
# we need a target that actually uses tests
executable('test_aarch64', 'empty_main.c', tests)

$ mkdir -p build && cd build
$ meson && ninja -v
[1/4] /usr/bin/aarch64-linux-gnu-gcc ../test.c -o test_aarch64.p/test
[2/4] /usr/bin/aarch64-linux-gnu-gcc ../test2.c -o test_aarch64.p/test2
-lpthread
[3/4] ccache cc -Itest_aarch64.p -I. -I.. -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -MD -MQ
test_aarch64.p/empty_main.c.o -MF test_aarch64.p/empty_main.c.o.d -o
test_aarch64.p/empty_main.c.o -c ../empty_main.c
[4/4] cc  -o test_aarch64 test_aarch64.p/empty_main.c.o -Wl,--as-needed
-Wl,--no-undefined
$ file test_aarch64.p/test*
test_aarch64.p/test:  ELF 64-bit LSB pie executable, ARM aarch64,
version 1 (SYSV), dynamically linked, interpreter
/lib/ld-linux-aarch64.so.1,
BuildID[sha1]=8162b8f045880c75118958ad46be78ed75bb708d, for GNU/Linux
3.7.0, not stripped
test_aarch64.p/test2: ELF 64-bit LSB pie executable, ARM aarch64,
version 1 (SYSV), dynamically linked, interpreter
/lib/ld-linux-aarch64.so.1,
BuildID[sha1]=eed48625e02cd436a2708f94e5dd9ce6d5c162a9, for GNU/Linux
3.7.0, not stripped
```

We'll need to remove the mechanic to build cross compilers containers.
In my experience, it's clunky anyway and fails when building several
from scratch. Try it yourself after cleaning your docker/podman images.
It's just better and simpler to expect user to install cross compilers.

The only thing that prevented me to implement this before is that I
didn't know if concerned maintainers would accept it, or just hold onto
the precious handcrafted Makefiles, into which so much energy and time
has been spent.
If it's not the case, then we should definitely move into the direction
of migrating all this to meson, and rely on meson tests infrastructure.

Regards,
Pierrick

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/26/2026 3:47 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>
>>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>>>>> run.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>>>>> unsigned binaries are plenty for it.
>>>>>>>>>>
>>>>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>>>>
>>>>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>>>>> platform that might have optional binaries not built by default.
>>>>>>>>>
>>>>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>>>>> have three questions that should help to provide a suggestion.
>>>>>>>>
>>>>>>>> Which exact test command do you run?
>>>>>>>
>>>>>>> make check-tcg
>>>>>>>
>>>>>>>>
>>>>>>>> ```
>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>> ensure they get built.
>>>>>>>> ```
>>>>>>>> Aren't they built by all?
>>>>>>>
>>>>>>> Apparently not.
>>>>>>>
>>>>>>>> It seems to be a dependency, at least for check-tcg:
>>>>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>>>>
>>>>>>>> ```
>>>>>>>> This is especially important for MacOS which otherwise only builds the
>>>>>>>> unsigned binaries on a normal "make all" run.
>>>>>>>> ```
>>>>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>>>>
>>>>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>>>>> to config-target.mak but the request was to fix the dependencies
>>>>>>> instead.
>>>>>>>
>>>>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>>>>> because the meson emulators target mechanism should be the same.
>>>>>>>
>>>>>>
>>>>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>>>>> does not build any target beyond tests). Maybe you forgot to clean your
>>>>>> folder?
>>>>>>
>>>>>
>>>>> The root issue is that tests/Makefile.include is included *after*
>>>>> evaluation of ninja-targets in main Makefile. Thus,
>>>>> .ninja-goals.check-tcg is ignored.
>>>>
>>>> So this replaces patch 1/16 - I think we have a circular dependency here.
>>>>
>>>
>>> Indeed, I didn't notice the duplication. While it solves things under
>>> Linux, it doesn't trigger any build on MacOS, which is what you observed
>>> also. I wonder if it's a gmake vs whatever-make difference.
>>>
>>> Another solution that seems ok on both platforms is to use (harmful)
>>> recursive make:
>>>
>>>  .PHONY: check-tcg
>>> -.ninja-goals.check-tcg = all test-plugins
>>> -check-tcg: $(RUN_TCG_TARGET_RULES)
>>> +check-tcg:
>>> + $(MAKE) all test-plugins
>>> + $(MAKE) $(RUN_TCG_TARGET_RULES)
>>>
>>>  .PHONY: clean-tcg
>>>  clean-tcg: $(CLEAN_TCG_TARGET_RULES)
>>>
>>> Or maybe just leave it as it is? Doc already mentions build should be
>>> done before running any test to avoid missing binaries.
>>> Hopefully we'll completely move tcg tests to meson one day, so there is
>>> no need to deal with make idiosyncrasy anymore.
>> 
>> The blocker for that to happen would be meson knowing about anything
>> else than the host compiler and singular cross compiler.
>>
>
> Meson indeed supports a single compiler + cross compiler at a time.
> However, you can directly generate cross binaries using a custom_target
> or a generator object. This way, meson would generate programs without
> having to know it's a C compiler. Since all files are single source,

That is an incorrect assumption - the softmmu binaries especially have a
multiple objects which are linked together.

> it's not a problem, since we don't need to declare them.
> Generators have the advantage of being less verbose (you declare only
> once how to use them) than custom target when used several times.
>
> https://mesonbuild.com/Reference-manual_functions_generator.html
> https://mesonbuild.com/Generating-sources.html#using-generator
>
> See a full working example below:
> ```
> $ cat meson.build
> project('cross_compile_tests', 'c')
>
> cc_aarch64 = generator(
>                find_program('aarch64-linux-gnu-gcc'),
>                arguments: ['@INPUT@', '-o', '@OUTPUT@', '@EXTRA_ARGS@'],
>                output: '@BASENAME@')
>
> tests = [
>   cc_aarch64.process('test.c'),
>   cc_aarch64.process('test2.c', extra_args: '-lpthread')
> ]
> # we need a target that actually uses tests
> executable('test_aarch64', 'empty_main.c', tests)
>
> $ mkdir -p build && cd build
> $ meson && ninja -v
> [1/4] /usr/bin/aarch64-linux-gnu-gcc ../test.c -o test_aarch64.p/test
> [2/4] /usr/bin/aarch64-linux-gnu-gcc ../test2.c -o test_aarch64.p/test2
> -lpthread
> [3/4] ccache cc -Itest_aarch64.p -I. -I.. -fdiagnostics-color=always
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -MD -MQ
> test_aarch64.p/empty_main.c.o -MF test_aarch64.p/empty_main.c.o.d -o
> test_aarch64.p/empty_main.c.o -c ../empty_main.c
> [4/4] cc  -o test_aarch64 test_aarch64.p/empty_main.c.o -Wl,--as-needed
> -Wl,--no-undefined
> $ file test_aarch64.p/test*
> test_aarch64.p/test:  ELF 64-bit LSB pie executable, ARM aarch64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib/ld-linux-aarch64.so.1,
> BuildID[sha1]=8162b8f045880c75118958ad46be78ed75bb708d, for GNU/Linux
> 3.7.0, not stripped
> test_aarch64.p/test2: ELF 64-bit LSB pie executable, ARM aarch64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib/ld-linux-aarch64.so.1,
> BuildID[sha1]=eed48625e02cd436a2708f94e5dd9ce6d5c162a9, for GNU/Linux
> 3.7.0, not stripped
> ```
>
> We'll need to remove the mechanic to build cross compilers containers.
> In my experience, it's clunky anyway and fails when building several
> from scratch. Try it yourself after cleaning your docker/podman images.
> It's just better and simpler to expect user to install cross
> compilers.

That would loose a bunch of functionality and doesn't help users running
anything that isn't Debian.

> The only thing that prevented me to implement this before is that I
> didn't know if concerned maintainers would accept it, or just hold onto
> the precious handcrafted Makefiles, into which so much energy and time
> has been spent.

There is no desire to hold onto Makefiles, but I do want to keep the
same capabilities as the current system. The driver for containerising
the compilers was that setting up cross compilers is a barrier to
contributors who want to be able to add and build tests.

> If it's not the case, then we should definitely move into the direction
> of migrating all this to meson, and rely on meson tests infrastructure.
>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/26/2026 10:58 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/26/2026 3:47 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>
>>>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>>>>>> run.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>>>>>> unsigned binaries are plenty for it.
>>>>>>>>>>>
>>>>>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>>>>>
>>>>>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>>>>>> platform that might have optional binaries not built by default.
>>>>>>>>>>
>>>>>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>>>>>> have three questions that should help to provide a suggestion.
>>>>>>>>>
>>>>>>>>> Which exact test command do you run?
>>>>>>>>
>>>>>>>> make check-tcg
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>> ensure they get built.
>>>>>>>>> ```
>>>>>>>>> Aren't they built by all?
>>>>>>>>
>>>>>>>> Apparently not.
>>>>>>>>
>>>>>>>>> It seems to be a dependency, at least for check-tcg:
>>>>>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>>>>>
>>>>>>>>> ```
>>>>>>>>> This is especially important for MacOS which otherwise only builds the
>>>>>>>>> unsigned binaries on a normal "make all" run.
>>>>>>>>> ```
>>>>>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>>>>>
>>>>>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>>>>>> to config-target.mak but the request was to fix the dependencies
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>>>>>> because the meson emulators target mechanism should be the same.
>>>>>>>>
>>>>>>>
>>>>>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>>>>>> does not build any target beyond tests). Maybe you forgot to clean your
>>>>>>> folder?
>>>>>>>
>>>>>>
>>>>>> The root issue is that tests/Makefile.include is included *after*
>>>>>> evaluation of ninja-targets in main Makefile. Thus,
>>>>>> .ninja-goals.check-tcg is ignored.
>>>>>
>>>>> So this replaces patch 1/16 - I think we have a circular dependency here.
>>>>>
>>>>
>>>> Indeed, I didn't notice the duplication. While it solves things under
>>>> Linux, it doesn't trigger any build on MacOS, which is what you observed
>>>> also. I wonder if it's a gmake vs whatever-make difference.
>>>>
>>>> Another solution that seems ok on both platforms is to use (harmful)
>>>> recursive make:
>>>>
>>>>  .PHONY: check-tcg
>>>> -.ninja-goals.check-tcg = all test-plugins
>>>> -check-tcg: $(RUN_TCG_TARGET_RULES)
>>>> +check-tcg:
>>>> + $(MAKE) all test-plugins
>>>> + $(MAKE) $(RUN_TCG_TARGET_RULES)
>>>>
>>>>  .PHONY: clean-tcg
>>>>  clean-tcg: $(CLEAN_TCG_TARGET_RULES)
>>>>
>>>> Or maybe just leave it as it is? Doc already mentions build should be
>>>> done before running any test to avoid missing binaries.
>>>> Hopefully we'll completely move tcg tests to meson one day, so there is
>>>> no need to deal with make idiosyncrasy anymore.
>>>
>>> The blocker for that to happen would be meson knowing about anything
>>> else than the host compiler and singular cross compiler.
>>>
>>
>> Meson indeed supports a single compiler + cross compiler at a time.
>> However, you can directly generate cross binaries using a custom_target
>> or a generator object. This way, meson would generate programs without
>> having to know it's a C compiler. Since all files are single source,
> 
> That is an incorrect assumption - the softmmu binaries especially have a
> multiple objects which are linked together.
>

custom_target can solves this.
*Most* of tcg tests are single source.

>> it's not a problem, since we don't need to declare them.
>> Generators have the advantage of being less verbose (you declare only
>> once how to use them) than custom target when used several times.
>>
>> https://mesonbuild.com/Reference-manual_functions_generator.html
>> https://mesonbuild.com/Generating-sources.html#using-generator
>>
>> See a full working example below:
>> ```
>> $ cat meson.build
>> project('cross_compile_tests', 'c')
>>
>> cc_aarch64 = generator(
>>                find_program('aarch64-linux-gnu-gcc'),
>>                arguments: ['@INPUT@', '-o', '@OUTPUT@', '@EXTRA_ARGS@'],
>>                output: '@BASENAME@')
>>
>> tests = [
>>   cc_aarch64.process('test.c'),
>>   cc_aarch64.process('test2.c', extra_args: '-lpthread')
>> ]
>> # we need a target that actually uses tests
>> executable('test_aarch64', 'empty_main.c', tests)
>>
>> $ mkdir -p build && cd build
>> $ meson && ninja -v
>> [1/4] /usr/bin/aarch64-linux-gnu-gcc ../test.c -o test_aarch64.p/test
>> [2/4] /usr/bin/aarch64-linux-gnu-gcc ../test2.c -o test_aarch64.p/test2
>> -lpthread
>> [3/4] ccache cc -Itest_aarch64.p -I. -I.. -fdiagnostics-color=always
>> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -MD -MQ
>> test_aarch64.p/empty_main.c.o -MF test_aarch64.p/empty_main.c.o.d -o
>> test_aarch64.p/empty_main.c.o -c ../empty_main.c
>> [4/4] cc  -o test_aarch64 test_aarch64.p/empty_main.c.o -Wl,--as-needed
>> -Wl,--no-undefined
>> $ file test_aarch64.p/test*
>> test_aarch64.p/test:  ELF 64-bit LSB pie executable, ARM aarch64,
>> version 1 (SYSV), dynamically linked, interpreter
>> /lib/ld-linux-aarch64.so.1,
>> BuildID[sha1]=8162b8f045880c75118958ad46be78ed75bb708d, for GNU/Linux
>> 3.7.0, not stripped
>> test_aarch64.p/test2: ELF 64-bit LSB pie executable, ARM aarch64,
>> version 1 (SYSV), dynamically linked, interpreter
>> /lib/ld-linux-aarch64.so.1,
>> BuildID[sha1]=eed48625e02cd436a2708f94e5dd9ce6d5c162a9, for GNU/Linux
>> 3.7.0, not stripped
>> ```
>>
>> We'll need to remove the mechanic to build cross compilers containers.
>> In my experience, it's clunky anyway and fails when building several
>> from scratch. Try it yourself after cleaning your docker/podman images.
>> It's just better and simpler to expect user to install cross
>> compilers.
> 
> That would loose a bunch of functionality and doesn't help users running
> anything that isn't Debian.
>

Out of fedora, who does it exclude?
We can still provide a fat debian container with all cross compilers
embedded for people who don't run ubuntu/debian.

>> The only thing that prevented me to implement this before is that I
>> didn't know if concerned maintainers would accept it, or just hold onto
>> the precious handcrafted Makefiles, into which so much energy and time
>> has been spent.
> 
> There is no desire to hold onto Makefiles, but I do want to keep the
> same capabilities as the current system. The driver for containerising
> the compilers was that setting up cross compilers is a barrier to
> contributors who want to be able to add and build tests.
>

Personally, this "smart" layer has been a barrier even on Debian, since
by default it tries to build them, and it fails from scratch.
Give it a try by purging your docker images, and run a make check-tcg
-j$(nproc). I doubt anyone is really running check-tcg with this in real
life.

But well, if the cross-container thing is *really* a blocker, we can
just wrap build and run in a script per cross compiler, that does
docker/podman build && docker/podman run and call that.

Now we solved the problem with system tests, and cross compilers, is
there another thing that is absolutely needed from Makefiles?

>> If it's not the case, then we should definitely move into the direction
>> of migrating all this to meson, and rely on meson tests infrastructure.
>>
>> Regards,
>> Pierrick
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/26/2026 10:58 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/26/2026 3:47 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>
>>>>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
<snip>
>>>
>>> We'll need to remove the mechanic to build cross compilers containers.
>>> In my experience, it's clunky anyway and fails when building several
>>> from scratch. Try it yourself after cleaning your docker/podman images.
>>> It's just better and simpler to expect user to install cross
>>> compilers.
>> 
>> That would loose a bunch of functionality and doesn't help users running
>> anything that isn't Debian.
>>
>
> Out of fedora, who does it exclude?

RHEL, CentOS, SuSE

The cross compiler situation may have improved since - Debian has always
been ahead of the curve in its multi-arch support.

> We can still provide a fat debian container with all cross compilers
> embedded for people who don't run ubuntu/debian.
>
>>> The only thing that prevented me to implement this before is that I
>>> didn't know if concerned maintainers would accept it, or just hold onto
>>> the precious handcrafted Makefiles, into which so much energy and time
>>> has been spent.
>> 
>> There is no desire to hold onto Makefiles, but I do want to keep the
>> same capabilities as the current system. The driver for containerising
>> the compilers was that setting up cross compilers is a barrier to
>> contributors who want to be able to add and build tests.
>>
>
> Personally, this "smart" layer has been a barrier even on Debian, since
> by default it tries to build them, and it fails from scratch.
> Give it a try by purging your docker images, and run a make check-tcg
> -j$(nproc). I doubt anyone is really running check-tcg with this in real
> life.

What do you mean? I run check-tcg all the time.

Which containers fail to build for you? The main cross-compiler one
(debian-all-test-cross) is built all the time.

> But well, if the cross-container thing is *really* a blocker, we can
> just wrap build and run in a script per cross compiler, that does
> docker/podman build && docker/podman run and call that.

We still have the remnants of that in the docker.py script although for
most containers we moved to invoking docker (or podman) directly.

Also bear in mind the containers are also used to cross build QEMU
itself. 

>
> Now we solved the problem with system tests, and cross compilers, is
> there another thing that is absolutely needed from Makefiles?
>
>>> If it's not the case, then we should definitely move into the direction
>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>
>>> Regards,
>>> Pierrick
>> 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/26/2026 11:17 PM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/26/2026 10:58 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/26/2026 3:47 AM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>>>>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>
>>>>>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
> <snip>
>>>>
>>>> We'll need to remove the mechanic to build cross compilers containers.
>>>> In my experience, it's clunky anyway and fails when building several
>>>> from scratch. Try it yourself after cleaning your docker/podman images.
>>>> It's just better and simpler to expect user to install cross
>>>> compilers.
>>>
>>> That would loose a bunch of functionality and doesn't help users running
>>> anything that isn't Debian.
>>>
>>
>> Out of fedora, who does it exclude?
> 
> RHEL, CentOS, SuSE
> 
> The cross compiler situation may have improved since - Debian has always
> been ahead of the curve in its multi-arch support.
> 
>> We can still provide a fat debian container with all cross compilers
>> embedded for people who don't run ubuntu/debian.
>>
>>>> The only thing that prevented me to implement this before is that I
>>>> didn't know if concerned maintainers would accept it, or just hold onto
>>>> the precious handcrafted Makefiles, into which so much energy and time
>>>> has been spent.
>>>
>>> There is no desire to hold onto Makefiles, but I do want to keep the
>>> same capabilities as the current system. The driver for containerising
>>> the compilers was that setting up cross compilers is a barrier to
>>> contributors who want to be able to add and build tests.
>>>
>>
>> Personally, this "smart" layer has been a barrier even on Debian, since
>> by default it tries to build them, and it fails from scratch.
>> Give it a try by purging your docker images, and run a make check-tcg
>> -j$(nproc). I doubt anyone is really running check-tcg with this in real
>> life.
> 
> What do you mean? I run check-tcg all the time.
> 
> Which containers fail to build for you? The main cross-compiler one
> (debian-all-test-cross) is built all the time.
>

Build is working out of the box now.
However, it seems that only tests for aarch64, arm and x86_64 are run
when using containers without having installed cross compilers.
Maybe it's another carefully handcrafted feature of tcg Makefiles?

>> But well, if the cross-container thing is *really* a blocker, we can
>> just wrap build and run in a script per cross compiler, that does
>> docker/podman build && docker/podman run and call that.
> 
> We still have the remnants of that in the docker.py script although for
> most containers we moved to invoking docker (or podman) directly.
>

Maybe that's why I encountered issues in the past, and now it works out
of the box.

> Also bear in mind the containers are also used to cross build QEMU
> itself. 
> 
>>
>> Now we solved the problem with system tests, and cross compilers, is
>> there another thing that is absolutely needed from Makefiles?
>>
>>>> If it's not the case, then we should definitely move into the direction
>>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>>

To add on top of this, I would be happy to help with the transition, but
I want to make sure you'll accept it first, with a list of requirements.

I'm a bit tired of seeing patches in your subsystems get stuck for
weeks, without any proper review, to finally be (re)posted again in a
new series, blocked for more weeks, and finally reach upstream one month
later or worse. It's truly exhausting for everyone contributing in such
places.

>>>> Regards,
>>>> Pierrick
>>>
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
<snip>
>> 
>> What do you mean? I run check-tcg all the time.
>> 
>> Which containers fail to build for you? The main cross-compiler one
>> (debian-all-test-cross) is built all the time.
>>
>
> Build is working out of the box now.
> However, it seems that only tests for aarch64, arm and x86_64 are run
> when using containers without having installed cross compilers.
> Maybe it's another carefully handcrafted feature of tcg Makefiles?

Works for me over here. Do you have podman or docker installed?

It's true the Makefile has to jump through some hoops to compute
TCG_TESTS_TARGETS from TCG_TESTS_WITH_COMPILERS (config-host.mak) and
CONFIGURED_TCG_TARGETS (via $(wildcard *-config-target.h)). Is that
where it fails?

As I've said before I'm not wedded to Makefiles, in fact I would look
forward to a world when I can run an individual test directly from
meson. However I'm not prepared to throw away functionality, especially
the ability of new developers/testers to build the tests without having
to install cross-compilers. That would take us back to the *before
times* when TCG tests where hardly ever run and tended to bitrot.

>>> But well, if the cross-container thing is *really* a blocker, we can
>>> just wrap build and run in a script per cross compiler, that does
>>> docker/podman build && docker/podman run and call that.
>> 
>> We still have the remnants of that in the docker.py script although for
>> most containers we moved to invoking docker (or podman) directly.
>>
>
> Maybe that's why I encountered issues in the past, and now it works out
> of the box.

The original script attempted to deal with caching layers and the
consequences of custom USER/UID on local machines. Nowadays it is mostly
used as a basic wrapper around "probe" for the runtime and is still used
by the binfmt_misc and toolchain wrappers.

For porting to meson it might be worth just having a minimal wrapper
just for building rather than mess with it.

>> Also bear in mind the containers are also used to cross build QEMU
>> itself. 
>> 
>>>
>>> Now we solved the problem with system tests, and cross compilers, is
>>> there another thing that is absolutely needed from Makefiles?
>>>
>>>>> If it's not the case, then we should definitely move into the direction
>>>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>>>
>
> To add on top of this, I would be happy to help with the transition, but
> I want to make sure you'll accept it first, with a list of
> requirements.

For check-tcg the requirements are simple:

  - support building tests with containers
  - handle all existing tests
    - per-arch *-user and *-softmmu
      - including post test validation checks (conditional-diff-out, validate-memory-counts.py, etc...)
      - per-target overrides (some targets are broken for some tests)
      - custom QEMU_OPTS for some tests
      - including sub-arch tests (e.g. x86_64 includes i386, mips64el includes mips64 etc...)
    - multiarch tests for all *-user targets
    - multiarch tests for all *-softmmu targets with boot.S
    - gdbstub tests
      - don't forget gdb feature probing for arch and arch features (e.g. GDB_HAS_SME_TILES)
    - record/replay tests
    - tcg plugin tests
      - modulate plugins over tests to avoid combinatorial explosion
      - filter some plugins from general testing (e.g. patch)
      - filter some plugins based on mode (e.g. syscall)
      - specific plugins with specific tests (e.g. patch, memory)
    - support build variations
      - compiler feature probing to gate tests
      - custom cflags for some tests
      - alternate cflag builds for some tests (e.g. sha512-[vector|sse|mvx|...])
      - build scripts (e.g. test-mmx.py)

with meson TCG_TEST_FILTER should be obsolete.

> I'm a bit tired of seeing patches in your subsystems get stuck for
> weeks, without any proper review, to finally be (re)posted again in a
> new series, blocked for more weeks, and finally reach upstream one month
> later or worse. It's truly exhausting for everyone contributing in such
> places.

What can I say - reviews are welcome. I always list what patches are
still waiting for review in the cover letter. I should also add for
testing/next I try to be extra careful that regressions don't slip in
because keeping the testing sub-system stable is important to support
things like bisection.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/28/2026 3:13 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
> <snip>
>>>
>>> What do you mean? I run check-tcg all the time.
>>>
>>> Which containers fail to build for you? The main cross-compiler one
>>> (debian-all-test-cross) is built all the time.
>>>
>>
>> Build is working out of the box now.
>> However, it seems that only tests for aarch64, arm and x86_64 are run
>> when using containers without having installed cross compilers.
>> Maybe it's another carefully handcrafted feature of tcg Makefiles?
> 
> Works for me over here. Do you have podman or docker installed?
> 
> It's true the Makefile has to jump through some hoops to compute
> TCG_TESTS_TARGETS from TCG_TESTS_WITH_COMPILERS (config-host.mak) and
> CONFIGURED_TCG_TARGETS (via $(wildcard *-config-target.h)). Is that
> where it fails?
>

Maybe, I reproduced that on two different machines, with different
architectures. As you know, Makefiles are complex to debug, which is one
of the reason I would like to get rid of it completely.

I prefer to spend time replacing this, instead of investigating N days
to understand why a dependency is missing (similar to the current patch)
and solve it by adding new cryptic lines in an existing Makefile.

> As I've said before I'm not wedded to Makefiles, in fact I would look
> forward to a world when I can run an individual test directly from
> meson. However I'm not prepared to throw away functionality, especially
> the ability of new developers/testers to build the tests without having
> to install cross-compilers. That would take us back to the *before
> times* when TCG tests where hardly ever run and tended to bitrot.
>

Sure, I agree with you. The transition should not change anything,
except how to run a single test. We can easily replicate the container
functionality in meson I think.

I just had the impression, previously in this thread, that instead of
saying "Sounds good, let's explore the meson approach", the tone was
more "this is wrong and this can't work, please don't touch this". Maybe
it's just a communication issue.

I made the effort to show a minimal example to prove you can compile
stuff without having to declare a toolchain in meson, which was the
"blocker" you mentioned. The rest, multi files tests and using a
container instead of an installed cross compiler, are just small
details. The key is "we can build a custom binary using a custom command
with meson", and that's all we need to move forward.

>>>> But well, if the cross-container thing is *really* a blocker, we can
>>>> just wrap build and run in a script per cross compiler, that does
>>>> docker/podman build && docker/podman run and call that.
>>>
>>> We still have the remnants of that in the docker.py script although for
>>> most containers we moved to invoking docker (or podman) directly.
>>>
>>
>> Maybe that's why I encountered issues in the past, and now it works out
>> of the box.
> 
> The original script attempted to deal with caching layers and the
> consequences of custom USER/UID on local machines. Nowadays it is mostly
> used as a basic wrapper around "probe" for the runtime and is still used
> by the binfmt_misc and toolchain wrappers.
> 
> For porting to meson it might be worth just having a minimal wrapper
> just for building rather than mess with it.
>

Yep.

>>> Also bear in mind the containers are also used to cross build QEMU
>>> itself. 
>>>
>>>>
>>>> Now we solved the problem with system tests, and cross compilers, is
>>>> there another thing that is absolutely needed from Makefiles?
>>>>
>>>>>> If it's not the case, then we should definitely move into the direction
>>>>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>>>>
>>
>> To add on top of this, I would be happy to help with the transition, but
>> I want to make sure you'll accept it first, with a list of
>> requirements.
> 
> For check-tcg the requirements are simple:
>

Thanks for listing them. We can have specific test suites to address the
categorization. For the rest, there is nothing custom targets won't be
able to solve.
>   - support building tests with containers
>   - handle all existing tests
>     - per-arch *-user and *-softmmu
>       - including post test validation checks (conditional-diff-out, validate-memory-counts.py, etc...)
>       - per-target overrides (some targets are broken for some tests)
>       - custom QEMU_OPTS for some tests
>       - including sub-arch tests (e.g. x86_64 includes i386, mips64el includes mips64 etc...)
>     - multiarch tests for all *-user targets
>     - multiarch tests for all *-softmmu targets with boot.S
>     - gdbstub tests
>       - don't forget gdb feature probing for arch and arch features (e.g. GDB_HAS_SME_TILES)
>     - record/replay tests
>     - tcg plugin tests
>       - modulate plugins over tests to avoid combinatorial explosion
>       - filter some plugins from general testing (e.g. patch)
>       - filter some plugins based on mode (e.g. syscall)
>       - specific plugins with specific tests (e.g. patch, memory)
>     - support build variations
>       - compiler feature probing to gate tests
>       - custom cflags for some tests
>       - alternate cflag builds for some tests (e.g. sha512-[vector|sse|mvx|...])
>       - build scripts (e.g. test-mmx.py)

I have a proposal: How about I give it a try with a specific target
(let's say aarch64?), to try to cover user, system, and multi arch
tests, without the cross container as a first step.

This way, we can focus on testing part, agree on what works, what
doesn't, and iterate until having something nice.
Then, we can add cross container support, and finally add the rest of
targets. Once all of them are implemented, we can migrate check-tcg
command to this.

What do you think?

> 
> with meson TCG_TEST_FILTER should be obsolete.
> 
>> I'm a bit tired of seeing patches in your subsystems get stuck for
>> weeks, without any proper review, to finally be (re)posted again in a
>> new series, blocked for more weeks, and finally reach upstream one month
>> later or worse. It's truly exhausting for everyone contributing in such
>> places.
> 
> What can I say - reviews are welcome. I always list what patches are
> still waiting for review in the cover letter. I should also add for
> testing/next I try to be extra careful that regressions don't slip in
> because keeping the testing sub-system stable is important to support
> things like bisection.
> 

The main issue with your personal workflow, which is "reposting existing
series concatenated in a new single series", is that it adds a lot of
latency. Basically, if one patch fails, or is not reviewed, the whole
thing is blocked. And that is a problem. I don't see what it's supposed
to achieve, since it's halfway between a series, and a PR, without being
one or the other.

TLDR: the problem is how long things are between receiving reviewed-by,
and being in a pull request in your subsystems.

For instance, in current series, there are multiple sub series. Some of
them are fully reviewed and ready to go, they can be sent as PR
independently.

I remember you mentioned several times that you like to have a "single
branch". I have the same workflow, and it absolutely does not prevent to
send multiple PR or series in parallel.

If tooling is the limitation, please take a look to those (ugly) scripts
for inspiration. AI can probably rewrite this better than me in 10 min.
With this, sending a series or a PR is a complete no-op for me, I just
wait for CI to run, and send it when ready 2h later.

# prepare a PR from a given list of series on the mailing list
# it ensures every commit is reviewed and passes checkpatch
https://github.com/qualcomm/qemu/blob/pbouvier/master/pull_request_publish_from_series.sh
# it uses this script, which is used to send a series or PR,
# pushes branches on github/gitlab with CI on both platforms
https://github.com/qualcomm/qemu/blob/pbouvier/master/publish.sh
# Then I send the PR (from existing branch) using:
https://github.com/qualcomm/qemu/blob/pbouvier/master/pull_request_send.sh

Saying "people have to accept my tempo" is not acceptable. Fix the
tooling instead.

Regards,
Pierrick

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>> <snip>
>>>>
>>>> What do you mean? I run check-tcg all the time.
>>>>
>>>> Which containers fail to build for you? The main cross-compiler one
>>>> (debian-all-test-cross) is built all the time.
<snip>
>>> I'm a bit tired of seeing patches in your subsystems get stuck for
>>> weeks, without any proper review, to finally be (re)posted again in a
>>> new series, blocked for more weeks, and finally reach upstream one month
>>> later or worse. It's truly exhausting for everyone contributing in such
>>> places.
>> 
>> What can I say - reviews are welcome. I always list what patches are
>> still waiting for review in the cover letter. I should also add for
>> testing/next I try to be extra careful that regressions don't slip in
>> because keeping the testing sub-system stable is important to support
>> things like bisection.
>> 
>
> The main issue with your personal workflow, which is "reposting existing
> series concatenated in a new single series", is that it adds a lot of
> latency. Basically, if one patch fails, or is not reviewed, the whole
> thing is blocked. And that is a problem. I don't see what it's supposed
> to achieve, since it's halfway between a series, and a PR, without being
> one or the other.
>
> TLDR: the problem is how long things are between receiving reviewed-by,
> and being in a pull request in your subsystems.
>
> For instance, in current series, there are multiple sub series. Some of
> them are fully reviewed and ready to go, they can be sent as PR
> independently.
>
> I remember you mentioned several times that you like to have a "single
> branch". I have the same workflow, and it absolutely does not prevent to
> send multiple PR or series in parallel.

I do split stuff out when it makes sense, but look at testing/next:

e02df7f4810 * testing/next MAINTAINERS: Cover python.docker with Python library section
4fcb3a8c07a * MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
b554638aea6 * MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
8417a661600 * MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
0f57fbac5bc * MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path

Maintainers updates aren't critical to get in now.

f80f388a538 * gitlab: update issue template for binary test cases
4e7de923722 * gitlab: add MacOS 26 job on gitlab runner
e0692ad4b23 * gitlab: add initial MacOS 15 on gitlab runner
1299b5aec2f * ci: drop cirrus MacOS build

None of these matter without bellow

dd2db9273be * accel/tcg: move jit thread manipulation into do_tb_phys_invalidate

b60553095bb * tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
bcde94b9315 * tests/Makefile.include: fix typo in comment

Why take the chance to break the build when the changes are in service
of the wider patch? The more runs through the CI to shake out anything
the better.

> If tooling is the limitation, please take a look to those (ugly) scripts
> for inspiration. AI can probably rewrite this better than me in 10 min.
> With this, sending a series or a PR is a complete no-op for me, I just
> wait for CI to run, and send it when ready 2h later.

Tooling isn't the issue - but I'm never going to be doing multiple PRs a
week because each one has a degree of latency due to CI coverage.

> Saying "people have to accept my tempo" is not acceptable. Fix the
> tooling instead.

I think it is fundamentally down to the maintainer what tempo they are
happy and able to work at. If you wish to take on responsibility for more
areas of the code base then be my guest.

>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/28/2026 11:03 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>> <snip>
>>>>>
>>>>> What do you mean? I run check-tcg all the time.
>>>>>
>>>>> Which containers fail to build for you? The main cross-compiler one
>>>>> (debian-all-test-cross) is built all the time.
> <snip>
>>>> I'm a bit tired of seeing patches in your subsystems get stuck for
>>>> weeks, without any proper review, to finally be (re)posted again in a
>>>> new series, blocked for more weeks, and finally reach upstream one month
>>>> later or worse. It's truly exhausting for everyone contributing in such
>>>> places.
>>>
>>> What can I say - reviews are welcome. I always list what patches are
>>> still waiting for review in the cover letter. I should also add for
>>> testing/next I try to be extra careful that regressions don't slip in
>>> because keeping the testing sub-system stable is important to support
>>> things like bisection.
>>>
>>
>> The main issue with your personal workflow, which is "reposting existing
>> series concatenated in a new single series", is that it adds a lot of
>> latency. Basically, if one patch fails, or is not reviewed, the whole
>> thing is blocked. And that is a problem. I don't see what it's supposed
>> to achieve, since it's halfway between a series, and a PR, without being
>> one or the other.
>>
>> TLDR: the problem is how long things are between receiving reviewed-by,
>> and being in a pull request in your subsystems.
>>
>> For instance, in current series, there are multiple sub series. Some of
>> them are fully reviewed and ready to go, they can be sent as PR
>> independently.
>>
>> I remember you mentioned several times that you like to have a "single
>> branch". I have the same workflow, and it absolutely does not prevent to
>> send multiple PR or series in parallel.
> 
> I do split stuff out when it makes sense, but look at testing/next:
> 
> e02df7f4810 * testing/next MAINTAINERS: Cover python.docker with Python library section
> 4fcb3a8c07a * MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
> b554638aea6 * MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
> 8417a661600 * MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
> 0f57fbac5bc * MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
> 
> Maintainers updates aren't critical to get in now.
>

The more you wait, the more it might create conflicts. That's basic
software engineering, and where the term Continuous integration comes
from. It does not mean "run a GitLab pipeline", it means integrate
often, *continuously*, with low latency.

There has been concrete examples of why delaying created an issue in the
past. In the current series, "docker: Remove LegacyKeyValueFormat*"
basically blocks any other change in concerned files, as soon as it does
not land. At least those two could have been sent as soon as possible.

If you'd send a PR regularly (at least every week), it would be less a
problem. Miss the train? get the next one.

If you want a good analogy:
Problem is that your train is leaving at random time, and it has several
wagons, which increase the risk of a mechanical failure every time. As a
result, passengers are stuck waiting.

> f80f388a538 * gitlab: update issue template for binary test cases
> 4e7de923722 * gitlab: add MacOS 26 job on gitlab runner
> e0692ad4b23 * gitlab: add initial MacOS 15 on gitlab runner
> 1299b5aec2f * ci: drop cirrus MacOS build
> 
> None of these matter without bellow
> 
> dd2db9273be * accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
> 
> b60553095bb * tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
> bcde94b9315 * tests/Makefile.include: fix typo in comment
> 
> Why take the chance to break the build when the changes are in service
> of the wider patch? The more runs through the CI to shake out anything
> the better.
> 
>> If tooling is the limitation, please take a look to those (ugly) scripts
>> for inspiration. AI can probably rewrite this better than me in 10 min.
>> With this, sending a series or a PR is a complete no-op for me, I just
>> wait for CI to run, and send it when ready 2h later.
> 
> Tooling isn't the issue - but I'm never going to be doing multiple PRs a
> week because each one has a degree of latency due to CI coverage.
>

Sorry, but this sentence doesn't make any sense at all.
What is the "degree of latency due to CI coverage"?

CI takes less than 2 hours to run, you can run it 4 times within a
working day. 5 days a week. That's 20 chances to send a PR.
The only latency is human based, and a way to solve it is to automate.
Lack of tooling *is* the problem in this situation.

You can't take a lot of pride in automating things with AI, and claim
it's impossible to automate sending a series of patch and run a CI
pipeline from it. Use AI if you want, but please apply it everywhere
it's needed.

>> Saying "people have to accept my tempo" is not acceptable. Fix the
>> tooling instead.
> 
> I think it is fundamentally down to the maintainer what tempo they are
> happy and able to work at. If you wish to take on responsibility for more
> areas of the code base then be my guest.
>

There is a difference between being really busy and just adding latency
artificially because "I said so". We worked together, so I can make the
difference between the two.

I would be happy to help maintain any part that needs help. Maintaining
plugins was a suggestion that came from Richard, and yes, I was open to
do it for a long time, especially after experimenting weeks of latency
to see patches get merged, and this several times.

I stepped in for docs because we identified there was a need for it.
I also talked with you in private to help on linux-user and you
explicitly asked me to wait, without any specific reason. Now Helge is
maintaining it and doing an excellent job, I'm really glad he stepped in.

I would be happy to help co-maintain tests/tcg and help this move to
meson. Unfortunately, you snipped that part without even trying to
answer to my proposal of helping by making a small proof of concept.

Coming back to your proposal, do you wanna share maintainership on
tests/tcg/multiarch and tests/tcg?

>>
>> Regards,
>> Pierrick
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/28/2026 11:03 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>
>>>> <snip>
>>>>>>
>>>>>> What do you mean? I run check-tcg all the time.
>>>>>>
>>>>>> Which containers fail to build for you? The main cross-compiler one
>>>>>> (debian-all-test-cross) is built all the time.
>> <snip>
>>>>> I'm a bit tired of seeing patches in your subsystems get stuck for
>>>>> weeks, without any proper review, to finally be (re)posted again in a
>>>>> new series, blocked for more weeks, and finally reach upstream one month
>>>>> later or worse. It's truly exhausting for everyone contributing in such
>>>>> places.
>>>>
>>>> What can I say - reviews are welcome. I always list what patches are
>>>> still waiting for review in the cover letter. I should also add for
>>>> testing/next I try to be extra careful that regressions don't slip in
>>>> because keeping the testing sub-system stable is important to support
>>>> things like bisection.
>>>>
>>>
>>> The main issue with your personal workflow, which is "reposting existing
>>> series concatenated in a new single series", is that it adds a lot of
>>> latency. Basically, if one patch fails, or is not reviewed, the whole
>>> thing is blocked. And that is a problem. I don't see what it's supposed
>>> to achieve, since it's halfway between a series, and a PR, without being
>>> one or the other.
>>>
>>> TLDR: the problem is how long things are between receiving reviewed-by,
>>> and being in a pull request in your subsystems.
>>>
>>> For instance, in current series, there are multiple sub series. Some of
>>> them are fully reviewed and ready to go, they can be sent as PR
>>> independently.
>>>
>>> I remember you mentioned several times that you like to have a "single
>>> branch". I have the same workflow, and it absolutely does not prevent to
>>> send multiple PR or series in parallel.
>> 
>> I do split stuff out when it makes sense, but look at testing/next:
>> 
>> e02df7f4810 * testing/next MAINTAINERS: Cover python.docker with Python library section
>> 4fcb3a8c07a * MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
>> b554638aea6 * MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
>> 8417a661600 * MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
>> 0f57fbac5bc * MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
>> 
>> Maintainers updates aren't critical to get in now.
>>
>
> The more you wait, the more it might create conflicts. That's basic
> software engineering, and where the term Continuous integration comes
> from. It does not mean "run a GitLab pipeline", it means integrate
> often, *continuously*, with low latency.
>
> There has been concrete examples of why delaying created an issue in the
> past. In the current series, "docker: Remove LegacyKeyValueFormat*"
> basically blocks any other change in concerned files, as soon as it does
> not land. At least those two could have been sent as soon as possible.
>
> If you'd send a PR regularly (at least every week), it would be less a
> problem. Miss the train? get the next one.
>
> If you want a good analogy:
> Problem is that your train is leaving at random time, and it has several
> wagons, which increase the risk of a mechanical failure every time. As a
> result, passengers are stuck waiting.
>
>> f80f388a538 * gitlab: update issue template for binary test cases
>> 4e7de923722 * gitlab: add MacOS 26 job on gitlab runner
>> e0692ad4b23 * gitlab: add initial MacOS 15 on gitlab runner
>> 1299b5aec2f * ci: drop cirrus MacOS build
>> 
>> None of these matter without bellow
>> 
>> dd2db9273be * accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
>> 
>> b60553095bb * tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
>> bcde94b9315 * tests/Makefile.include: fix typo in comment
>> 
>> Why take the chance to break the build when the changes are in service
>> of the wider patch? The more runs through the CI to shake out anything
>> the better.
>> 
>>> If tooling is the limitation, please take a look to those (ugly) scripts
>>> for inspiration. AI can probably rewrite this better than me in 10 min.
>>> With this, sending a series or a PR is a complete no-op for me, I just
>>> wait for CI to run, and send it when ready 2h later.
>> 
>> Tooling isn't the issue - but I'm never going to be doing multiple PRs a
>> week because each one has a degree of latency due to CI coverage.
>>
>
> Sorry, but this sentence doesn't make any sense at all.
> What is the "degree of latency due to CI coverage"?
>
> CI takes less than 2 hours to run, you can run it 4 times within a
> working day. 5 days a week. That's 20 chances to send a PR.
> The only latency is human based, and a way to solve it is to automate.
> Lack of tooling *is* the problem in this situation.
>
> You can't take a lot of pride in automating things with AI, and claim
> it's impossible to automate sending a series of patch and run a CI
> pipeline from it. Use AI if you want, but please apply it everywhere
> it's needed.
>
>>> Saying "people have to accept my tempo" is not acceptable. Fix the
>>> tooling instead.
>> 
>> I think it is fundamentally down to the maintainer what tempo they are
>> happy and able to work at. If you wish to take on responsibility for more
>> areas of the code base then be my guest.
>>
>
> There is a difference between being really busy and just adding latency
> artificially because "I said so". We worked together, so I can make the
> difference between the two.
>
> I would be happy to help maintain any part that needs help. Maintaining
> plugins was a suggestion that came from Richard, and yes, I was open to
> do it for a long time, especially after experimenting weeks of latency
> to see patches get merged, and this several times.
>
> I stepped in for docs because we identified there was a need for it.
> I also talked with you in private to help on linux-user and you
> explicitly asked me to wait, without any specific reason. Now Helge is
> maintaining it and doing an excellent job, I'm really glad he stepped in.
>
> I would be happy to help co-maintain tests/tcg and help this move to
> meson. Unfortunately, you snipped that part without even trying to
> answer to my proposal of helping by making a small proof of concept.
>
> Coming back to your proposal, do you wanna share maintainership on
> tests/tcg/multiarch and tests/tcg?

I'm happy to turn over the maintinership of tests/tcg to you with the
new meson based system.

>
>>>
>>> Regards,
>>> Pierrick
>> 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 5/28/2026 1:04 PM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/28/2026 11:03 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>>>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>
>>>>> <snip>
>>>>>>>
>>>>>>> What do you mean? I run check-tcg all the time.
>>>>>>>
>>>>>>> Which containers fail to build for you? The main cross-compiler one
>>>>>>> (debian-all-test-cross) is built all the time.
>>> <snip>
>>>>>> I'm a bit tired of seeing patches in your subsystems get stuck for
>>>>>> weeks, without any proper review, to finally be (re)posted again in a
>>>>>> new series, blocked for more weeks, and finally reach upstream one month
>>>>>> later or worse. It's truly exhausting for everyone contributing in such
>>>>>> places.
>>>>>
>>>>> What can I say - reviews are welcome. I always list what patches are
>>>>> still waiting for review in the cover letter. I should also add for
>>>>> testing/next I try to be extra careful that regressions don't slip in
>>>>> because keeping the testing sub-system stable is important to support
>>>>> things like bisection.
>>>>>
>>>>
>>>> The main issue with your personal workflow, which is "reposting existing
>>>> series concatenated in a new single series", is that it adds a lot of
>>>> latency. Basically, if one patch fails, or is not reviewed, the whole
>>>> thing is blocked. And that is a problem. I don't see what it's supposed
>>>> to achieve, since it's halfway between a series, and a PR, without being
>>>> one or the other.
>>>>
>>>> TLDR: the problem is how long things are between receiving reviewed-by,
>>>> and being in a pull request in your subsystems.
>>>>
>>>> For instance, in current series, there are multiple sub series. Some of
>>>> them are fully reviewed and ready to go, they can be sent as PR
>>>> independently.
>>>>
>>>> I remember you mentioned several times that you like to have a "single
>>>> branch". I have the same workflow, and it absolutely does not prevent to
>>>> send multiple PR or series in parallel.
>>>
>>> I do split stuff out when it makes sense, but look at testing/next:
>>>
>>> e02df7f4810 * testing/next MAINTAINERS: Cover python.docker with Python library section
>>> 4fcb3a8c07a * MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
>>> b554638aea6 * MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
>>> 8417a661600 * MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
>>> 0f57fbac5bc * MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
>>>
>>> Maintainers updates aren't critical to get in now.
>>>
>>
>> The more you wait, the more it might create conflicts. That's basic
>> software engineering, and where the term Continuous integration comes
>> from. It does not mean "run a GitLab pipeline", it means integrate
>> often, *continuously*, with low latency.
>>
>> There has been concrete examples of why delaying created an issue in the
>> past. In the current series, "docker: Remove LegacyKeyValueFormat*"
>> basically blocks any other change in concerned files, as soon as it does
>> not land. At least those two could have been sent as soon as possible.
>>
>> If you'd send a PR regularly (at least every week), it would be less a
>> problem. Miss the train? get the next one.
>>
>> If you want a good analogy:
>> Problem is that your train is leaving at random time, and it has several
>> wagons, which increase the risk of a mechanical failure every time. As a
>> result, passengers are stuck waiting.
>>
>>> f80f388a538 * gitlab: update issue template for binary test cases
>>> 4e7de923722 * gitlab: add MacOS 26 job on gitlab runner
>>> e0692ad4b23 * gitlab: add initial MacOS 15 on gitlab runner
>>> 1299b5aec2f * ci: drop cirrus MacOS build
>>>
>>> None of these matter without bellow
>>>
>>> dd2db9273be * accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
>>>
>>> b60553095bb * tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
>>> bcde94b9315 * tests/Makefile.include: fix typo in comment
>>>
>>> Why take the chance to break the build when the changes are in service
>>> of the wider patch? The more runs through the CI to shake out anything
>>> the better.
>>>
>>>> If tooling is the limitation, please take a look to those (ugly) scripts
>>>> for inspiration. AI can probably rewrite this better than me in 10 min.
>>>> With this, sending a series or a PR is a complete no-op for me, I just
>>>> wait for CI to run, and send it when ready 2h later.
>>>
>>> Tooling isn't the issue - but I'm never going to be doing multiple PRs a
>>> week because each one has a degree of latency due to CI coverage.
>>>
>>
>> Sorry, but this sentence doesn't make any sense at all.
>> What is the "degree of latency due to CI coverage"?
>>
>> CI takes less than 2 hours to run, you can run it 4 times within a
>> working day. 5 days a week. That's 20 chances to send a PR.
>> The only latency is human based, and a way to solve it is to automate.
>> Lack of tooling *is* the problem in this situation.
>>
>> You can't take a lot of pride in automating things with AI, and claim
>> it's impossible to automate sending a series of patch and run a CI
>> pipeline from it. Use AI if you want, but please apply it everywhere
>> it's needed.
>>
>>>> Saying "people have to accept my tempo" is not acceptable. Fix the
>>>> tooling instead.
>>>
>>> I think it is fundamentally down to the maintainer what tempo they are
>>> happy and able to work at. If you wish to take on responsibility for more
>>> areas of the code base then be my guest.
>>>
>>
>> There is a difference between being really busy and just adding latency
>> artificially because "I said so". We worked together, so I can make the
>> difference between the two.
>>
>> I would be happy to help maintain any part that needs help. Maintaining
>> plugins was a suggestion that came from Richard, and yes, I was open to
>> do it for a long time, especially after experimenting weeks of latency
>> to see patches get merged, and this several times.
>>
>> I stepped in for docs because we identified there was a need for it.
>> I also talked with you in private to help on linux-user and you
>> explicitly asked me to wait, without any specific reason. Now Helge is
>> maintaining it and doing an excellent job, I'm really glad he stepped in.
>>
>> I would be happy to help co-maintain tests/tcg and help this move to
>> meson. Unfortunately, you snipped that part without even trying to
>> answer to my proposal of helping by making a small proof of concept.
>>
>> Coming back to your proposal, do you wanna share maintainership on
>> tests/tcg/multiarch and tests/tcg?
> 
> I'm happy to turn over the maintinership of tests/tcg to you with the
> new meson based system.
>

Sure. Let's focus on seeing how it will look like, and I'll be looking
forward to see your review of it.

>>
>>>>
>>>> Regards,
>>>> Pierrick
>>>
> 

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>> <snip>
>>>>
>>>> What do you mean? I run check-tcg all the time.
>>>>
>>>> Which containers fail to build for you? The main cross-compiler one
>>>> (debian-all-test-cross) is built all the time.
>>>>
>>>
>>> Build is working out of the box now.
>>> However, it seems that only tests for aarch64, arm and x86_64 are run
>>> when using containers without having installed cross compilers.
>>> Maybe it's another carefully handcrafted feature of tcg Makefiles?
>> 
>> Works for me over here. Do you have podman or docker installed?
>> 
>> It's true the Makefile has to jump through some hoops to compute
>> TCG_TESTS_TARGETS from TCG_TESTS_WITH_COMPILERS (config-host.mak) and
>> CONFIGURED_TCG_TARGETS (via $(wildcard *-config-target.h)). Is that
>> where it fails?
>>
>
> Maybe, I reproduced that on two different machines, with different
> architectures. As you know, Makefiles are complex to debug, which is one
> of the reason I would like to get rid of it completely.
>
> I prefer to spend time replacing this, instead of investigating N days
> to understand why a dependency is missing (similar to the current patch)
> and solve it by adding new cryptic lines in an existing Makefile.
>
>> As I've said before I'm not wedded to Makefiles, in fact I would look
>> forward to a world when I can run an individual test directly from
>> meson. However I'm not prepared to throw away functionality, especially
>> the ability of new developers/testers to build the tests without having
>> to install cross-compilers. That would take us back to the *before
>> times* when TCG tests where hardly ever run and tended to bitrot.
>>
>
> Sure, I agree with you. The transition should not change anything,
> except how to run a single test. We can easily replicate the container
> functionality in meson I think.
>
> I just had the impression, previously in this thread, that instead of
> saying "Sounds good, let's explore the meson approach", the tone was
> more "this is wrong and this can't work, please don't touch this". Maybe
> it's just a communication issue.
>
> I made the effort to show a minimal example to prove you can compile
> stuff without having to declare a toolchain in meson, which was the
> "blocker" you mentioned. The rest, multi files tests and using a
> container instead of an installed cross compiler, are just small
> details. The key is "we can build a custom binary using a custom command
> with meson", and that's all we need to move forward.
>
>>>>> But well, if the cross-container thing is *really* a blocker, we can
>>>>> just wrap build and run in a script per cross compiler, that does
>>>>> docker/podman build && docker/podman run and call that.
>>>>
>>>> We still have the remnants of that in the docker.py script although for
>>>> most containers we moved to invoking docker (or podman) directly.
>>>>
>>>
>>> Maybe that's why I encountered issues in the past, and now it works out
>>> of the box.
>> 
>> The original script attempted to deal with caching layers and the
>> consequences of custom USER/UID on local machines. Nowadays it is mostly
>> used as a basic wrapper around "probe" for the runtime and is still used
>> by the binfmt_misc and toolchain wrappers.
>> 
>> For porting to meson it might be worth just having a minimal wrapper
>> just for building rather than mess with it.
>>
>
> Yep.
>
>>>> Also bear in mind the containers are also used to cross build QEMU
>>>> itself. 
>>>>
>>>>>
>>>>> Now we solved the problem with system tests, and cross compilers, is
>>>>> there another thing that is absolutely needed from Makefiles?
>>>>>
>>>>>>> If it's not the case, then we should definitely move into the direction
>>>>>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>>>>>
>>>
>>> To add on top of this, I would be happy to help with the transition, but
>>> I want to make sure you'll accept it first, with a list of
>>> requirements.
>> 
>> For check-tcg the requirements are simple:
>>
>
> Thanks for listing them. We can have specific test suites to address the
> categorization. For the rest, there is nothing custom targets won't be
> able to solve.
>>   - support building tests with containers
>>   - handle all existing tests
>>     - per-arch *-user and *-softmmu
>>       - including post test validation checks (conditional-diff-out, validate-memory-counts.py, etc...)
>>       - per-target overrides (some targets are broken for some tests)
>>       - custom QEMU_OPTS for some tests
>>       - including sub-arch tests (e.g. x86_64 includes i386, mips64el includes mips64 etc...)
>>     - multiarch tests for all *-user targets
>>     - multiarch tests for all *-softmmu targets with boot.S
>>     - gdbstub tests
>>       - don't forget gdb feature probing for arch and arch features (e.g. GDB_HAS_SME_TILES)
>>     - record/replay tests
>>     - tcg plugin tests
>>       - modulate plugins over tests to avoid combinatorial explosion
>>       - filter some plugins from general testing (e.g. patch)
>>       - filter some plugins based on mode (e.g. syscall)
>>       - specific plugins with specific tests (e.g. patch, memory)
>>     - support build variations
>>       - compiler feature probing to gate tests
>>       - custom cflags for some tests
>>       - alternate cflag builds for some tests (e.g. sha512-[vector|sse|mvx|...])
>>       - build scripts (e.g. test-mmx.py)
>
> I have a proposal: How about I give it a try with a specific target
> (let's say aarch64?), to try to cover user, system, and multi arch
> tests, without the cross container as a first step.
>
> This way, we can focus on testing part, agree on what works, what
> doesn't, and iterate until having something nice.
> Then, we can add cross container support, and finally add the rest of
> targets. Once all of them are implemented, we can migrate check-tcg
> command to this.

I think that's a reasonable plan. We can certainly test and review
patches as we try different things out. aarch64 is a good first target
as it has user, softmmu and plugin specific tests.

What we can't do is merge piecemeal so I'd want a complete conversion
before we merge so we don't end up with a half-functional port to meson
in the tree (the bane of QEMU's API conversions).

<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

[Pierrick Bouvier]

On 6/3/2026 12:03 PM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>
>>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>
>>> <snip>
>>>>>
>>>>> What do you mean? I run check-tcg all the time.
>>>>>
>>>>> Which containers fail to build for you? The main cross-compiler one
>>>>> (debian-all-test-cross) is built all the time.
>>>>>
>>>>
>>>> Build is working out of the box now.
>>>> However, it seems that only tests for aarch64, arm and x86_64 are run
>>>> when using containers without having installed cross compilers.
>>>> Maybe it's another carefully handcrafted feature of tcg Makefiles?
>>>
>>> Works for me over here. Do you have podman or docker installed?
>>>
>>> It's true the Makefile has to jump through some hoops to compute
>>> TCG_TESTS_TARGETS from TCG_TESTS_WITH_COMPILERS (config-host.mak) and
>>> CONFIGURED_TCG_TARGETS (via $(wildcard *-config-target.h)). Is that
>>> where it fails?
>>>
>>
>> Maybe, I reproduced that on two different machines, with different
>> architectures. As you know, Makefiles are complex to debug, which is one
>> of the reason I would like to get rid of it completely.
>>
>> I prefer to spend time replacing this, instead of investigating N days
>> to understand why a dependency is missing (similar to the current patch)
>> and solve it by adding new cryptic lines in an existing Makefile.
>>
>>> As I've said before I'm not wedded to Makefiles, in fact I would look
>>> forward to a world when I can run an individual test directly from
>>> meson. However I'm not prepared to throw away functionality, especially
>>> the ability of new developers/testers to build the tests without having
>>> to install cross-compilers. That would take us back to the *before
>>> times* when TCG tests where hardly ever run and tended to bitrot.
>>>
>>
>> Sure, I agree with you. The transition should not change anything,
>> except how to run a single test. We can easily replicate the container
>> functionality in meson I think.
>>
>> I just had the impression, previously in this thread, that instead of
>> saying "Sounds good, let's explore the meson approach", the tone was
>> more "this is wrong and this can't work, please don't touch this". Maybe
>> it's just a communication issue.
>>
>> I made the effort to show a minimal example to prove you can compile
>> stuff without having to declare a toolchain in meson, which was the
>> "blocker" you mentioned. The rest, multi files tests and using a
>> container instead of an installed cross compiler, are just small
>> details. The key is "we can build a custom binary using a custom command
>> with meson", and that's all we need to move forward.
>>
>>>>>> But well, if the cross-container thing is *really* a blocker, we can
>>>>>> just wrap build and run in a script per cross compiler, that does
>>>>>> docker/podman build && docker/podman run and call that.
>>>>>
>>>>> We still have the remnants of that in the docker.py script although for
>>>>> most containers we moved to invoking docker (or podman) directly.
>>>>>
>>>>
>>>> Maybe that's why I encountered issues in the past, and now it works out
>>>> of the box.
>>>
>>> The original script attempted to deal with caching layers and the
>>> consequences of custom USER/UID on local machines. Nowadays it is mostly
>>> used as a basic wrapper around "probe" for the runtime and is still used
>>> by the binfmt_misc and toolchain wrappers.
>>>
>>> For porting to meson it might be worth just having a minimal wrapper
>>> just for building rather than mess with it.
>>>
>>
>> Yep.
>>
>>>>> Also bear in mind the containers are also used to cross build QEMU
>>>>> itself. 
>>>>>
>>>>>>
>>>>>> Now we solved the problem with system tests, and cross compilers, is
>>>>>> there another thing that is absolutely needed from Makefiles?
>>>>>>
>>>>>>>> If it's not the case, then we should definitely move into the direction
>>>>>>>> of migrating all this to meson, and rely on meson tests infrastructure.
>>>>>>>>
>>>>
>>>> To add on top of this, I would be happy to help with the transition, but
>>>> I want to make sure you'll accept it first, with a list of
>>>> requirements.
>>>
>>> For check-tcg the requirements are simple:
>>>
>>
>> Thanks for listing them. We can have specific test suites to address the
>> categorization. For the rest, there is nothing custom targets won't be
>> able to solve.
>>>   - support building tests with containers
>>>   - handle all existing tests
>>>     - per-arch *-user and *-softmmu
>>>       - including post test validation checks (conditional-diff-out, validate-memory-counts.py, etc...)
>>>       - per-target overrides (some targets are broken for some tests)
>>>       - custom QEMU_OPTS for some tests
>>>       - including sub-arch tests (e.g. x86_64 includes i386, mips64el includes mips64 etc...)
>>>     - multiarch tests for all *-user targets
>>>     - multiarch tests for all *-softmmu targets with boot.S
>>>     - gdbstub tests
>>>       - don't forget gdb feature probing for arch and arch features (e.g. GDB_HAS_SME_TILES)
>>>     - record/replay tests
>>>     - tcg plugin tests
>>>       - modulate plugins over tests to avoid combinatorial explosion
>>>       - filter some plugins from general testing (e.g. patch)
>>>       - filter some plugins based on mode (e.g. syscall)
>>>       - specific plugins with specific tests (e.g. patch, memory)
>>>     - support build variations
>>>       - compiler feature probing to gate tests
>>>       - custom cflags for some tests
>>>       - alternate cflag builds for some tests (e.g. sha512-[vector|sse|mvx|...])
>>>       - build scripts (e.g. test-mmx.py)
>>
>> I have a proposal: How about I give it a try with a specific target
>> (let's say aarch64?), to try to cover user, system, and multi arch
>> tests, without the cross container as a first step.
>>
>> This way, we can focus on testing part, agree on what works, what
>> doesn't, and iterate until having something nice.
>> Then, we can add cross container support, and finally add the rest of
>> targets. Once all of them are implemented, we can migrate check-tcg
>> command to this.
> 
> I think that's a reasonable plan. We can certainly test and review
> patches as we try different things out. aarch64 is a good first target
> as it has user, softmmu and plugin specific tests.
>

Yes, this should give us a good taste of what it will look like.

> What we can't do is merge piecemeal so I'd want a complete conversion
> before we merge so we don't end up with a half-functional port to meson
> in the tree (the bane of QEMU's API conversions).
>

100% agree. Even if it's a slow development over months, we'll replace
Makefiles only once all the features are properly covered.
 > <snip>
> 

Regards,
Pierrick

[PATCH v2 04/16] accel/tcg: move jit thread manipulation into do_tb_phys_invalidate

[Alex Bennée]

To invalidate a TB on MacOS we need to enable write access to the JIT
buffer. We were doing this for tb_phys_invalidate__locked but that is
not the only path into do_tb_phys_invalidate. Move the manipulation
into the shared function that does the work.

As a result we can drop the tb_phys_invalidate__locked function and
update the calls directly.

This enables watchpoints to work in MacOS TCG guests.

Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3444
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
v2
  - make everyone call do_tb_phys_invalidate
  - tweak the if statement so we don't miss unlocking on an early return
---
 accel/tcg/tb-maint.c | 43 +++++++++++++++++++------------------------
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/accel/tcg/tb-maint.c b/accel/tcg/tb-maint.c
index cd7c32361bb..0c7ac5a72c0 100644
--- a/accel/tcg/tb-maint.c
+++ b/accel/tcg/tb-maint.c
@@ -925,6 +925,7 @@ static void do_tb_phys_invalidate(TranslationBlock *tb, bool rm_from_page_list)
     uint32_t orig_cflags = tb_cflags(tb);
 
     assert_memory_lock();
+    qemu_thread_jit_write();
 
     /* make sure no further incoming jumps will be chained to this TB */
     qemu_spin_lock(&tb->jmp_lock);
@@ -935,33 +936,27 @@ static void do_tb_phys_invalidate(TranslationBlock *tb, bool rm_from_page_list)
     phys_pc = tb_page_addr0(tb);
     h = tb_hash_func(phys_pc, (orig_cflags & CF_PCREL ? 0 : tb->pc),
                      tb->flags, tb->cs_base, orig_cflags);
-    if (!qht_remove(&tb_ctx.htable, tb, h)) {
-        return;
-    }
+    if (qht_remove(&tb_ctx.htable, tb, h)) {
 
-    /* remove the TB from the page list */
-    if (rm_from_page_list) {
-        tb_remove(tb);
-    }
+        /* remove the TB from the page list */
+        if (rm_from_page_list) {
+            tb_remove(tb);
+        }
 
-    /* remove the TB from the hash list */
-    tb_jmp_cache_inval_tb(tb);
+        /* remove the TB from the hash list */
+        tb_jmp_cache_inval_tb(tb);
 
-    /* suppress this TB from the two jump lists */
-    tb_remove_from_jmp_list(tb, 0);
-    tb_remove_from_jmp_list(tb, 1);
+        /* suppress this TB from the two jump lists */
+        tb_remove_from_jmp_list(tb, 0);
+        tb_remove_from_jmp_list(tb, 1);
 
-    /* suppress any remaining jumps to this TB */
-    tb_jmp_unlink(tb);
+        /* suppress any remaining jumps to this TB */
+        tb_jmp_unlink(tb);
 
-    qatomic_set(&tb_ctx.tb_phys_invalidate_count,
-                tb_ctx.tb_phys_invalidate_count + 1);
-}
+        qatomic_set(&tb_ctx.tb_phys_invalidate_count,
+                    tb_ctx.tb_phys_invalidate_count + 1);
+    }
 
-static void tb_phys_invalidate__locked(TranslationBlock *tb)
-{
-    qemu_thread_jit_write();
-    do_tb_phys_invalidate(tb, true);
     qemu_thread_jit_execute();
 }
 
@@ -1030,7 +1025,7 @@ void tb_invalidate_phys_range(CPUState *cpu, tb_page_addr_t start,
     assert_memory_lock();
 
     PAGE_FOR_EACH_TB(start, last, unused, tb, n) {
-        tb_phys_invalidate__locked(tb);
+        do_tb_phys_invalidate(tb, true);
     }
 }
 
@@ -1091,7 +1086,7 @@ bool tb_invalidate_phys_page_unwind(CPUState *cpu, tb_page_addr_t addr,
             current_tb_modified = true;
             cpu_restore_state_from_tb(cpu, current_tb, pc);
         }
-        tb_phys_invalidate__locked(tb);
+        do_tb_phys_invalidate(tb, true);
     }
 
     if (current_tb_modified) {
@@ -1156,7 +1151,7 @@ tb_invalidate_phys_page_range__locked(CPUState *cpu,
                 current_tb_modified = true;
                 cpu_restore_state_from_tb(cpu, current_tb, retaddr);
             }
-            tb_phys_invalidate__locked(tb);
+            do_tb_phys_invalidate(tb, true);
         }
     }
 
-- 
2.47.3

[PATCH v2 05/16] ci: drop cirrus MacOS build

[Alex Bennée]

CirrusCI is closing down soon so time to migrate.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/lcitool/refresh             |  1 -
 .gitlab-ci.d/cirrus.yml           | 14 --------------
 .gitlab-ci.d/cirrus/macos-14.vars | 16 ----------------
 3 files changed, 31 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/macos-14.vars

diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index e4d01d792b7..fa4a16e3583 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -311,7 +311,6 @@ try:
     # Cirrus packages lists for GitLab
     #
     generate_cirrus("freebsd-14")
-    generate_cirrus("macos-14")
 
     #
     # VM packages lists
diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index f2a9a64b76a..b71ab090b65 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -44,17 +44,3 @@ x64-freebsd-14-build:
     INSTALL_COMMAND: pkg install -y
     CONFIGURE_ARGS: --target-list-exclude=arm-softmmu,i386-softmmu,mips64el-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4eb-softmmu,xtensa-softmmu --enable-rust
     TEST_TARGETS: check
-
-aarch64-macos-build:
-  extends: .cirrus_build_job
-  variables:
-    NAME: macos-14
-    CIRRUS_VM_INSTANCE_TYPE: macos_instance
-    CIRRUS_VM_IMAGE_SELECTOR: image
-    CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-runner:sonoma
-    UPDATE_COMMAND: brew update
-    INSTALL_COMMAND: brew install
-    PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
-    PKG_CONFIG_PATH: /opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
-    CONFIGURE_ARGS: --target-list-exclude=arm-softmmu,i386-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4-softmmu,xtensaeb-softmmu --enable-rust
-    TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat check-qtest-x86_64
diff --git a/.gitlab-ci.d/cirrus/macos-14.vars b/.gitlab-ci.d/cirrus/macos-14.vars
deleted file mode 100644
index def77cfdea5..00000000000
--- a/.gitlab-ci.d/cirrus/macos-14.vars
+++ /dev/null
@@ -1,16 +0,0 @@
-# THIS FILE WAS AUTO-GENERATED
-#
-#  $ lcitool variables macos-14 qemu
-#
-# https://gitlab.com/libvirt/libvirt-ci
-
-CCACHE='/opt/homebrew/bin/ccache'
-CPAN_PKGS=''
-CROSS_PKGS=''
-MAKE='/opt/homebrew/bin/gmake'
-NINJA='/opt/homebrew/bin/ninja'
-PACKAGING_COMMAND='brew'
-PIP3='/opt/homebrew/bin/pip3'
-PKGS='bash bc bindgen bison bzip2 capstone ccache cmocka coreutils ctags curl dbus diffutils dtc flex gcovr gettext git glib gnu-sed gnutls gtk+3 gtk-vnc jemalloc jpeg-turbo json-c libcbor libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 libusb llvm lzo make meson mtools ncurses nettle ninja pixman pkg-config python-setuptools python3 rpm2cpio rust sdl2 sdl2_image snappy socat sparse spice-protocol swtpm tesseract usbredir vde vte3 vulkan-tools xorriso zlib zstd'
-PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme tomli'
-PYTHON='/opt/homebrew/bin/python3'
-- 
2.47.3

Re: [PATCH v2 05/16] ci: drop cirrus MacOS build

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> CirrusCI is closing down soon so time to migrate.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>  tests/lcitool/refresh             |  1 -
>  .gitlab-ci.d/cirrus.yml           | 14 --------------
>  .gitlab-ci.d/cirrus/macos-14.vars | 16 ----------------
>  3 files changed, 31 deletions(-)
>  delete mode 100644 .gitlab-ci.d/cirrus/macos-14.vars
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

[PATCH v2 06/16] gitlab: add initial MacOS 15 on gitlab runner

[Alex Bennée]

The gitlab runners are currently in beta but available to projects on
the Premium and Ultimate plans (which QEMU is via the Open Source
program).

We install some compilers via brew so we can run some of the check-tcg
softmmu test cases.

We disable rust as the version is too old.

We disable plugins because we haven't taught the test harness about
.dynlib vs .so yet.

There is a discrepancy between the vars and version of MacOS because
lcitool needs teaching about other versions (although I don't think it
matters as brew is shared across versions).

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
v2
  - call tcg run directly to work around makefile issues
  - drop debug lines
---
 tests/lcitool/refresh         | 11 ++++++++
 .gitlab-ci.d/macos-14.vars    | 16 ++++++++++++
 .gitlab-ci.d/macos.yml        | 47 +++++++++++++++++++++++++++++++++++
 .gitlab-ci.d/qemu-project.yml |  1 +
 4 files changed, 75 insertions(+)
 create mode 100644 .gitlab-ci.d/macos-14.vars
 create mode 100644 .gitlab-ci.d/macos.yml

diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index fa4a16e3583..4289cc381a6 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -87,6 +87,12 @@ def generate_cirrus(target, trailer=None):
     generate(filename, cmd, trailer)
 
 
+def generate_vars(target, trailer=None):
+    filename = Path(src_dir, ".gitlab-ci.d", target + ".vars")
+    cmd = lcitool_cmd + ["variables", "--format", "shell", target, "qemu"]
+    generate(filename, cmd, trailer)
+
+
 def generate_pkglist(vm, target, project="qemu"):
     filename = Path(src_dir, "tests", "vm", "generated", vm + ".json")
     cmd = lcitool_cmd + ["variables", "--format", "json", target, project]
@@ -312,6 +318,11 @@ try:
     #
     generate_cirrus("freebsd-14")
 
+    #
+    # GitLab packages lists
+    #
+    generate_vars("macos-14")
+
     #
     # VM packages lists
     #
diff --git a/.gitlab-ci.d/macos-14.vars b/.gitlab-ci.d/macos-14.vars
new file mode 100644
index 00000000000..def77cfdea5
--- /dev/null
+++ b/.gitlab-ci.d/macos-14.vars
@@ -0,0 +1,16 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables macos-14 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+CCACHE='/opt/homebrew/bin/ccache'
+CPAN_PKGS=''
+CROSS_PKGS=''
+MAKE='/opt/homebrew/bin/gmake'
+NINJA='/opt/homebrew/bin/ninja'
+PACKAGING_COMMAND='brew'
+PIP3='/opt/homebrew/bin/pip3'
+PKGS='bash bc bindgen bison bzip2 capstone ccache cmocka coreutils ctags curl dbus diffutils dtc flex gcovr gettext git glib gnu-sed gnutls gtk+3 gtk-vnc jemalloc jpeg-turbo json-c libcbor libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 libusb llvm lzo make meson mtools ncurses nettle ninja pixman pkg-config python-setuptools python3 rpm2cpio rust sdl2 sdl2_image snappy socat sparse spice-protocol swtpm tesseract usbredir vde vte3 vulkan-tools xorriso zlib zstd'
+PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme tomli'
+PYTHON='/opt/homebrew/bin/python3'
diff --git a/.gitlab-ci.d/macos.yml b/.gitlab-ci.d/macos.yml
new file mode 100644
index 00000000000..c93bf12a294
--- /dev/null
+++ b/.gitlab-ci.d/macos.yml
@@ -0,0 +1,47 @@
+.macos_job_template:
+  extends: .base_job_template
+  stage: build
+  tags:
+    - saas-macos-large-m2pro
+  needs: []
+  timeout: 80m
+  artifacts:
+    name: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
+    expire_in: 7 days
+    paths:
+      - build/meson-logs/
+      - build/tests/tcg/
+    reports:
+      junit: build/meson-logs/*.junit.xml
+    when: always
+  before_script:
+    - set -o allexport
+    - source .gitlab-ci.d/macos-14.vars
+    - set +o allexport
+    - export PATH="$PATH_EXTRA:$PATH"
+    - export PKG_CONFIG_PATH="$PKG_CONFIG_PATH"
+    - brew update
+    - brew install $PKGS
+    - brew install gdb aarch64-elf-gcc i686-elf-gcc x86_64-elf-gcc
+    - if test -n "$PYPI_PKGS" ; then PYLIB=$($PYTHON -c 'import sysconfig; print(sysconfig.get_path("stdlib"))'); rm -f $PYLIB/EXTERNALLY-MANAGED; $PIP3 install --break-system-packages $PYPI_PKGS ; fi
+  script:
+    - mkdir build
+    - cd build
+    - ../configure --enable-werror $CONFIGURE_ARGS || { cat config.log meson-logs/meson-log.txt; exit 1; }
+    - $MAKE -j$(sysctl -n hw.ncpu)
+    - for TARGET in $TEST_TARGETS ; do $MAKE $TARGET ; done
+
+aarch64-macos-15-build:
+  extends: .macos_job_template
+  image: macos-15-xcode-16
+  variables:
+    NAME: macos-15
+    PATH_EXTRA: /opt/homebrew/gettext/bin
+    PKG_CONFIG_PATH: /opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+    CONFIGURE_ARGS:
+        --target-list=aarch64-softmmu,i386-softmmu,x86_64-softmmu
+        --cross-prefix-aarch64=aarch64-elf-
+        --cross-prefix-i386=i686-elf-
+        --cross-prefix-x86_64=x86_64-elf-
+        --disable-plugins
+    TEST_TARGETS: check-unit run-tcg-tests-aarch64-softmmu run-tcg-tests-i386-softmmu run-tcg-tests-x86_64-softmmu
diff --git a/.gitlab-ci.d/qemu-project.yml b/.gitlab-ci.d/qemu-project.yml
index 4d914c4897b..9cbb5fe787f 100644
--- a/.gitlab-ci.d/qemu-project.yml
+++ b/.gitlab-ci.d/qemu-project.yml
@@ -19,3 +19,4 @@ include:
   - local: '/.gitlab-ci.d/custom-runners.yml'
   - local: '/.gitlab-ci.d/cirrus.yml'
   - local: '/.gitlab-ci.d/windows.yml'
+  - local: '/.gitlab-ci.d/macos.yml'
-- 
2.47.3

Re: [PATCH v2 06/16] gitlab: add initial MacOS 15 on gitlab runner

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> The gitlab runners are currently in beta but available to projects on
> the Premium and Ultimate plans (which QEMU is via the Open Source
> program).
> 
> We install some compilers via brew so we can run some of the check-tcg
> softmmu test cases.
> 
> We disable rust as the version is too old.
> 
> We disable plugins because we haven't taught the test harness about
> .dynlib vs .so yet.
> 
> There is a discrepancy between the vars and version of MacOS because
> lcitool needs teaching about other versions (although I don't think it
> matters as brew is shared across versions).
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> 
> ---
> v2
>   - call tcg run directly to work around makefile issues
>   - drop debug lines
> ---
>  tests/lcitool/refresh         | 11 ++++++++
>  .gitlab-ci.d/macos-14.vars    | 16 ++++++++++++
>  .gitlab-ci.d/macos.yml        | 47 +++++++++++++++++++++++++++++++++++
>  .gitlab-ci.d/qemu-project.yml |  1 +
>  4 files changed, 75 insertions(+)
>  create mode 100644 .gitlab-ci.d/macos-14.vars
>  create mode 100644 .gitlab-ci.d/macos.yml
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

[PATCH v2 07/16] gitlab: add MacOS 26 job on gitlab runner

[Alex Bennée]

gitlab supports 3 MacOS images with 15 and 26 being the current
supported ones. To get ahead of the curve lets enable 26 as well.

It re-uses the same brew list but also attempts to work around python
configure failure by setting DYLD_LIBRARY_PATH:
/opt/homebrew/opt/expat/lib/

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---

v2
  - call runners directly, seems to be working now
  - drop debug lines
---
 .gitlab-ci.d/macos.yml | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/.gitlab-ci.d/macos.yml b/.gitlab-ci.d/macos.yml
index c93bf12a294..f61750a3f4a 100644
--- a/.gitlab-ci.d/macos.yml
+++ b/.gitlab-ci.d/macos.yml
@@ -45,3 +45,19 @@ aarch64-macos-15-build:
         --cross-prefix-x86_64=x86_64-elf-
         --disable-plugins
     TEST_TARGETS: check-unit run-tcg-tests-aarch64-softmmu run-tcg-tests-i386-softmmu run-tcg-tests-x86_64-softmmu
+
+aarch64-macos-26-build:
+  extends: .macos_job_template
+  image: macos-26-xcode-26
+  variables:
+    NAME: macos-26
+    DYLD_LIBRARY_PATH: /opt/homebrew/opt/expat/lib/
+    PATH_EXTRA: /opt/homebrew/gettext/bin
+    PKG_CONFIG_PATH: /opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+    CONFIGURE_ARGS:
+        --target-list=aarch64-softmmu,i386-softmmu,x86_64-softmmu
+        --cross-prefix-aarch64=aarch64-elf-
+        --cross-prefix-i386=i686-elf-
+        --cross-prefix-x86_64=x86_64-elf-
+        --disable-plugins
+    TEST_TARGETS: check-unit run-tcg-tests-aarch64-softmmu run-tcg-tests-i386-softmmu run-tcg-tests-x86_64-softmmu
-- 
2.47.3

Re: [PATCH v2 07/16] gitlab: add MacOS 26 job on gitlab runner

[Pierrick Bouvier]

On 5/21/2026 6:17 AM, Alex Bennée wrote:
> gitlab supports 3 MacOS images with 15 and 26 being the current
> supported ones. To get ahead of the curve lets enable 26 as well.
> 
> It re-uses the same brew list but also attempts to work around python
> configure failure by setting DYLD_LIBRARY_PATH:
> /opt/homebrew/opt/expat/lib/
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> 
> ---
> 
> v2
>   - call runners directly, seems to be working now
>   - drop debug lines
> ---
>  .gitlab-ci.d/macos.yml | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

[PATCH v2 08/16] gitlab: update issue template for binary test cases

[Alex Bennée]

Binary test cases are sketchy because they can be vectors for phishing
and other malware. Lets strongly hint that source bases tests are
preferred and binaries should have their provenance declared.

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260511161757.105994-1-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .gitlab/issue_templates/bug.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/.gitlab/issue_templates/bug.md b/.gitlab/issue_templates/bug.md
index 53a79f58284..e20f586008d 100644
--- a/.gitlab/issue_templates/bug.md
+++ b/.gitlab/issue_templates/bug.md
@@ -55,6 +55,10 @@ https://www.qemu.org/contribute/security-process/
 <!--
 Attach logs, stack traces, screenshots, etc. Compress the files if necessary.
 If using libvirt, libvirt logs and XML domain information may be relevant.
+
+If attaching binary test cases you should describe where they were obtained
+from, preferably linking to the original source. We greatly prefer test cases in
+the form of source code that can be audited before compiling by the engineer.
 -->
 
 <!--
-- 
2.47.3

[PATCH v2 09/16] MAINTAINERS: add a section for AI agents

[Alex Bennée]

For completeness add a section to MAINTAINERS to catch changes should
we decide to merge this.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b75f3222f2f..6b61a23893a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4576,6 +4576,12 @@ M: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
 S: Maintained
 F: docs/
 
+AI agents
+M: Alex Bennée <alex.bennee@linaro.org>
+S: Maintained
+F: .agents/skills/
+F: AGENTS.md
+
 Build System
 ------------
 Meson
-- 
2.47.3

[PATCH v2 10/16] MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Fixes: afbdf0a44ea ("docker: Add Hexagon image")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-2-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6b61a23893a..5fadf2cfcc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -257,7 +257,7 @@ F: linux-user/hexagon/
 F: tests/tcg/hexagon/
 F: disas/hexagon.c
 F: configs/targets/hexagon-linux-user/default.mak
-F: docker/dockerfiles/debian-hexagon-cross.docker
+F: tests/docker/dockerfiles/debian-hexagon-cross.docker
 F: gdbstub/gdb-xml/hexagon*.xml
 T: git https://github.com/quic/qemu.git hex-next
 
-- 
2.47.3

[PATCH v2 11/16] MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-3-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5fadf2cfcc7..03ec57efe75 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -280,6 +280,7 @@ LoongArch TCG CPUs
 M: Song Gao <gaosong@loongson.cn>
 S: Maintained
 F: target/loongarch/
+F: tests/docker/dockerfiles/debian-loongarch-cross.docker
 F: tests/tcg/loongarch64/
 F: tests/functional/loongarch64/meson.build
 F: tests/functional/loongarch64/test_virt.py
-- 
2.47.3

[PATCH v2 12/16] MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-4-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03ec57efe75..c04fc1cd2e8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -445,6 +445,7 @@ W: http://wiki.osll.ru/doku.php?id=etc:users:jcmvbkbc:qemu-target-xtensa
 S: Maintained
 F: target/xtensa/
 F: hw/xtensa/
+F: tests/docker/dockerfiles/debian-xtensa-cross.docker
 F: tests/functional/xtensa/meson.build
 F: tests/tcg/xtensa/
 F: tests/tcg/xtensaeb/
-- 
2.47.3

[PATCH v2 13/16] MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-5-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c04fc1cd2e8..62754d18341 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -458,6 +458,7 @@ S: Orphan
 F: target/tricore/
 F: hw/tricore/
 F: include/hw/tricore/
+F: tests/docker/dockerfiles/debian-tricore-cross.docker
 F: tests/tcg/tricore/
 
 Multiarch Linux User Tests
-- 
2.47.3

[PATCH v2 14/16] MAINTAINERS: Cover python.docker with Python library section

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-6-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 62754d18341..bc054a6d97b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3484,6 +3484,7 @@ M: John Snow <jsnow@redhat.com>
 M: Cleber Rosa <crosa@redhat.com>
 S: Maintained
 F: python/
+F: tests/docker/dockerfiles/python.docker
 T: git https://gitlab.com/jsnow/qemu.git python
 
 Python scripts
-- 
2.47.3

[PATCH v2 15/16] docker: Remove LegacyKeyValueFormat warnings in non-generated files

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Manually update Dockerfiles to not use legacy 'ENV key value' format:
https://docs.docker.com/reference/build-checks/legacy-key-value-format/

This removes warnings when building / using the containers:

 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 98)
 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 64)
 - LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 97)

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Reviewed-by: Brian Cain <brian.cain@oss.qualcomm.com>
Message-ID: <20260518102222.80735-7-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .../docker/dockerfiles/debian-hexagon-cross.docker | 14 +++++++-------
 .../dockerfiles/debian-loongarch-cross.docker      | 10 +++++-----
 .../docker/dockerfiles/debian-tricore-cross.docker |  6 +++---
 .../docker/dockerfiles/debian-xtensa-cross.docker  |  8 ++++----
 tests/docker/dockerfiles/python.docker             |  5 +++--
 scripts/coverity-scan/coverity-scan.docker         | 12 ++++++------
 6 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 91d4b71ac95..3c94f040b81 100644
--- a/tests/docker/dockerfiles/debian-hexagon-cross.docker
+++ b/tests/docker/dockerfiles/debian-hexagon-cross.docker
@@ -39,15 +39,15 @@ RUN apt-get update && \
     ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/gcc && \
     dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
 
-ENV TOOLCHAIN_INSTALL /opt
-ENV TOOLCHAIN_RELEASE 12.Dec.2023
-ENV TOOLCHAIN_BASENAME "clang+llvm-${TOOLCHAIN_RELEASE}-cross-hexagon-unknown-linux-musl"
-ENV TOOLCHAIN_URL https://codelinaro.jfrog.io/artifactory/codelinaro-toolchain-for-hexagon/${TOOLCHAIN_RELEASE}/${TOOLCHAIN_BASENAME}.tar.xz
-ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers"
+ENV TOOLCHAIN_INSTALL=/opt
+ENV TOOLCHAIN_RELEASE=12.Dec.2023
+ENV TOOLCHAIN_BASENAME=clang+llvm-${TOOLCHAIN_RELEASE}-cross-hexagon-unknown-linux-musl
+ENV TOOLCHAIN_URL=https://codelinaro.jfrog.io/artifactory/codelinaro-toolchain-for-hexagon/${TOOLCHAIN_RELEASE}/${TOOLCHAIN_BASENAME}.tar.xz
+ENV CCACHE_WRAPPERSDIR=/usr/libexec/ccache-wrappers
 
 RUN curl -#SL "$TOOLCHAIN_URL" | tar -xJC "$TOOLCHAIN_INSTALL"
-ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin
-ENV MAKE /usr/bin/make
+ENV PATH=$PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin
+ENV MAKE=/usr/bin/make
 # As a final step configure the user (if env is defined)
 ARG USER
 ARG UID
diff --git a/tests/docker/dockerfiles/debian-loongarch-cross.docker b/tests/docker/dockerfiles/debian-loongarch-cross.docker
index 55b3dbe4510..d2ba07972ce 100644
--- a/tests/docker/dockerfiles/debian-loongarch-cross.docker
+++ b/tests/docker/dockerfiles/debian-loongarch-cross.docker
@@ -40,12 +40,12 @@ RUN apt-get update && \
 RUN curl -#SL https://github.com/loongson/build-tools/releases/download/2023.08.08/CLFS-loongarch64-8.1-x86_64-cross-tools-gcc-glibc.tar.xz \
     | tar -xJC /opt
 
-ENV PATH $PATH:/opt/cross-tools/bin
-ENV LD_LIBRARY_PATH /opt/cross-tools/lib:/opt/cross-tools/loongarch64-unknown-linux-gnu/lib:$LD_LIBRARY_PATH
+ENV PATH=$PATH:/opt/cross-tools/bin
+ENV LD_LIBRARY_PATH=/opt/cross-tools/lib:/opt/cross-tools/loongarch64-unknown-linux-gnu/lib:$LD_LIBRARY_PATH
 
-ENV QEMU_CONFIGURE_OPTS --disable-docs --disable-tools
-ENV DEF_TARGET_LIST loongarch64-linux-user,loongarch64-softmmu
-ENV MAKE /usr/bin/make
+ENV QEMU_CONFIGURE_OPTS="--disable-docs --disable-tools"
+ENV DEF_TARGET_LIST=loongarch64-linux-user,loongarch64-softmmu
+ENV MAKE=/usr/bin/make
 
 # As a final step configure the user (if env is defined)
 ARG USER
diff --git a/tests/docker/dockerfiles/debian-tricore-cross.docker b/tests/docker/dockerfiles/debian-tricore-cross.docker
index fd797dc7ee4..9e7ff321677 100644
--- a/tests/docker/dockerfiles/debian-tricore-cross.docker
+++ b/tests/docker/dockerfiles/debian-tricore-cross.docker
@@ -40,9 +40,9 @@ RUN curl -#SL https://github.com/bkoppelmann/package_940/releases/download/trico
     | tar -xzC /usr/local/
 
 # This image can only build a very minimal QEMU as well as the tests
-ENV DEF_TARGET_LIST tricore-softmmu
-ENV QEMU_CONFIGURE_OPTS --disable-user --disable-tools --disable-fdt
-ENV MAKE /usr/bin/make
+ENV DEF_TARGET_LIST=tricore-softmmu
+ENV QEMU_CONFIGURE_OPTS="--disable-user --disable-tools --disable-fdt"
+ENV MAKE=/usr/bin/make
 # As a final step configure the user (if env is defined)
 ARG USER
 ARG UID
diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker b/tests/docker/dockerfiles/debian-xtensa-cross.docker
index ef63e44e2ef..d9130fc3378 100644
--- a/tests/docker/dockerfiles/debian-xtensa-cross.docker
+++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
@@ -19,16 +19,16 @@ RUN apt-get update && \
         python3-minimal && \
     dpkg-query --showformat '${Package}_${Version}_${Architecture}\n' --show > /packages.txt
 
-ENV CPU_LIST dc232b dc233c de233_fpu dsp3400
-ENV TOOLCHAIN_RELEASE 2020.07
+ENV CPU_LIST="dc232b dc233c de233_fpu dsp3400"
+ENV TOOLCHAIN_RELEASE=2020.07
 
 RUN for cpu in $CPU_LIST; do \
         curl -#SL http://github.com/foss-xtensa/toolchain/releases/download/$TOOLCHAIN_RELEASE/x86_64-$TOOLCHAIN_RELEASE-xtensa-$cpu-elf.tar.gz \
         | tar -xzC /opt; \
     done
 
-ENV PATH $PATH:/opt/$TOOLCHAIN_RELEASE/xtensa-dc232b-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-dc233c-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-de233_fpu-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-dsp3400-elf/bin
-ENV MAKE /usr/bin/make
+ENV PATH=$PATH:/opt/$TOOLCHAIN_RELEASE/xtensa-dc232b-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-dc233c-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-de233_fpu-elf/bin:/opt/$TOOLCHAIN_RELEASE/xtensa-dsp3400-elf/bin
+ENV MAKE=/usr/bin/make
 # As a final step configure the user (if env is defined)
 ARG USER
 ARG UID
diff --git a/tests/docker/dockerfiles/python.docker b/tests/docker/dockerfiles/python.docker
index 59e70a02484..79c554a2d87 100644
--- a/tests/docker/dockerfiles/python.docker
+++ b/tests/docker/dockerfiles/python.docker
@@ -4,7 +4,7 @@ FROM fedora:latest
 MAINTAINER John Snow <jsnow@redhat.com>
 
 # Please keep this list sorted alphabetically
-ENV PACKAGES \
+ENV PACKAGES="\
     gcc \
     make \
     python3 \
@@ -15,7 +15,8 @@ ENV PACKAGES \
     python3.11 \
     python3.12 \
     python3.13 \
-    python3.9
+    python3.9 \
+    "
 
 RUN dnf install -y $PACKAGES
 RUN rpm -q $PACKAGES | sort > /packages.txt
diff --git a/scripts/coverity-scan/coverity-scan.docker b/scripts/coverity-scan/coverity-scan.docker
index 93e558c8623..30d154c0d86 100644
--- a/scripts/coverity-scan/coverity-scan.docker
+++ b/scripts/coverity-scan/coverity-scan.docker
@@ -152,12 +152,12 @@ exec "$@"' > /usr/bin/nosync && \
     ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/g++ && \
     ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/gcc
 
-ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers"
-ENV LANG "en_US.UTF-8"
-ENV MAKE "/usr/bin/make"
-ENV NINJA "/usr/bin/ninja"
-ENV PYTHON "/usr/bin/python3"
-ENV QEMU_CONFIGURE_OPTS --meson=internal
+ENV CCACHE_WRAPPERSDIR=/usr/libexec/ccache-wrappers
+ENV LANG=en_US.UTF-8
+ENV MAKE=/usr/bin/make
+ENV NINJA=/usr/bin/ninja
+ENV PYTHON=/usr/bin/python3
+ENV QEMU_CONFIGURE_OPTS=--meson=internal
 
 RUN dnf install -y curl wget
 ENV COVERITY_TOOL_BASE=/coverity-tools
-- 
2.47.3

[PATCH v2 16/16] docker: Remove LegacyKeyValueFormat warnings in generated files

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@linaro.org>

Display lcitool changes before generated ones.

Update lcitool refresh script to not use legacy 'ENV key value'
format:
https://docs.docker.com/reference/build-checks/legacy-key-value-format/

Run "make lcitool-refresh" to update the generated container files.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
Message-ID: <20260518102222.80735-8-philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 tests/lcitool/refresh                                | 12 +++++++-----
 tests/docker/dockerfiles/alpine.docker               |  2 +-
 tests/docker/dockerfiles/centos9.docker              |  2 +-
 .../docker/dockerfiles/debian-all-test-cross.docker  | 10 ++++++----
 tests/docker/dockerfiles/debian-amd64-cross.docker   |  2 +-
 tests/docker/dockerfiles/debian-arm64-cross.docker   |  2 +-
 tests/docker/dockerfiles/debian-armhf-cross.docker   |  2 +-
 tests/docker/dockerfiles/debian-i686-cross.docker    |  2 +-
 .../docker/dockerfiles/debian-mips64el-cross.docker  |  2 +-
 tests/docker/dockerfiles/debian-mipsel-cross.docker  |  2 +-
 tests/docker/dockerfiles/debian-ppc64el-cross.docker |  2 +-
 tests/docker/dockerfiles/debian-riscv64-cross.docker |  2 +-
 tests/docker/dockerfiles/debian-s390x-cross.docker   |  2 +-
 tests/docker/dockerfiles/debian.docker               |  2 +-
 tests/docker/dockerfiles/fedora-rust-nightly.docker  |  2 +-
 tests/docker/dockerfiles/fedora-win64-cross.docker   |  2 +-
 tests/docker/dockerfiles/fedora.docker               |  2 +-
 tests/docker/dockerfiles/opensuse-leap.docker        |  2 +-
 scripts/git.orderfile                                |  4 ++++
 19 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 4289cc381a6..d4d19e72ec6 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -77,7 +77,7 @@ def generate_dockerfile(host, target, project="qemu", cross=None, trailer=None,
         trailer = "\n".join(add_user_mapping)
 
     if enable_rust:
-        trailer += "\nENV ENABLE_RUST 1\n"
+        trailer += "\nENV ENABLE_RUST=1\n"
     generate(filename, cmd, trailer)
 
 
@@ -175,7 +175,8 @@ debian_all_test_cross_compilers = [
     "  dpkg-dev\\\n",
     "  gdb-multiarch\\\n",
     "  libclang-rt-dev\n",
-    "ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \\\n",
+    "ENV AVAILABLE_COMPILERS=\"\\\n",
+    "  gcc-aarch64-linux-gnu \\\n",
     "  libc6-dev-arm64-cross \\\n",
     "  gcc-arm-linux-gnueabihf \\\n",
     "  libc6-dev-armhf-cross \\\n",
@@ -196,7 +197,8 @@ debian_all_test_cross_compilers = [
     "  gcc-s390x-linux-gnu \\\n",
     "  libc6-dev-s390x-cross\\\n",
     "  gcc-sh4-linux-gnu \\\n",
-    "  libc6-dev-sh4-cross\n",
+    "  libc6-dev-sh4-cross \\\n",
+    "  \"\n",
     "RUN if dpkg-architecture -e amd64; then \\\n",
     "  export AVAILABLE_COMPILERS=\"${AVAILABLE_COMPILERS} gcc-hppa-linux-gnu libc6-dev-hppa-cross\"; \\\n",
     "  export AVAILABLE_COMPILERS=\"${AVAILABLE_COMPILERS} gcc-m68k-linux-gnu libc6-dev-m68k-cross\"; \\\n",
@@ -208,8 +210,8 @@ debian_all_test_cross_compilers = [
     "apt install -y --no-install-recommends \\\n",
     "${AVAILABLE_COMPILERS} && \\\n",
     "dpkg-query --showformat '${Package}_${Version}_${Architecture}' --show > /packages.txt\n",
-    "ENV QEMU_CONFIGURE_OPTS --disable-docs\n",
-    "ENV DEF_TARGET_LIST aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,i386-linux-user,m68k-linux-user,mips-linux-user,mips64-linux-user,mips64el-linux-user,mipsel-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,riscv64-linux-user,s390x-linux-user,sh4-linux-user,sparc64-linux-user\n",
+    "ENV QEMU_CONFIGURE_OPTS=--disable-docs\n",
+    "ENV DEF_TARGET_LIST=aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,i386-linux-user,m68k-linux-user,mips-linux-user,mips64-linux-user,mips64el-linux-user,mipsel-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,riscv64-linux-user,s390x-linux-user,sh4-linux-user,sparc64-linux-user\n",
 ]
 
 def cross_build(prefix, targets):
diff --git a/tests/docker/dockerfiles/alpine.docker b/tests/docker/dockerfiles/alpine.docker
index a7ee85fcda7..118c6e8eeaf 100644
--- a/tests/docker/dockerfiles/alpine.docker
+++ b/tests/docker/dockerfiles/alpine.docker
@@ -141,4 +141,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/centos9.docker b/tests/docker/dockerfiles/centos9.docker
index 41a1225856e..0d5b5fa7f59 100644
--- a/tests/docker/dockerfiles/centos9.docker
+++ b/tests/docker/dockerfiles/centos9.docker
@@ -145,4 +145,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-all-test-cross.docker b/tests/docker/dockerfiles/debian-all-test-cross.docker
index 287770a995a..a10ffc73500 100644
--- a/tests/docker/dockerfiles/debian-all-test-cross.docker
+++ b/tests/docker/dockerfiles/debian-all-test-cross.docker
@@ -61,7 +61,8 @@ RUN DEBIAN_FRONTEND=noninteractive eatmydata \
   dpkg-dev\
   gdb-multiarch\
   libclang-rt-dev
-ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
+ENV AVAILABLE_COMPILERS="\
+  gcc-aarch64-linux-gnu \
   libc6-dev-arm64-cross \
   gcc-arm-linux-gnueabihf \
   libc6-dev-armhf-cross \
@@ -82,7 +83,8 @@ ENV AVAILABLE_COMPILERS gcc-aarch64-linux-gnu \
   gcc-s390x-linux-gnu \
   libc6-dev-s390x-cross\
   gcc-sh4-linux-gnu \
-  libc6-dev-sh4-cross
+  libc6-dev-sh4-cross \
+  "
 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"; \
@@ -94,8 +96,8 @@ DEBIAN_FRONTEND=noninteractive eatmydata \
 apt install -y --no-install-recommends \
 ${AVAILABLE_COMPILERS} && \
 dpkg-query --showformat '${Package}_${Version}_${Architecture}' --show > /packages.txt
-ENV QEMU_CONFIGURE_OPTS --disable-docs
-ENV DEF_TARGET_LIST aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,i386-linux-user,m68k-linux-user,mips-linux-user,mips64-linux-user,mips64el-linux-user,mipsel-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,riscv64-linux-user,s390x-linux-user,sh4-linux-user,sparc64-linux-user
+ENV QEMU_CONFIGURE_OPTS=--disable-docs
+ENV DEF_TARGET_LIST=aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,i386-linux-user,m68k-linux-user,mips-linux-user,mips64-linux-user,mips64el-linux-user,mipsel-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,riscv64-linux-user,s390x-linux-user,sh4-linux-user,sparc64-linux-user
 # As a final step configure the user (if env is defined)
 ARG USER
 ARG UID
diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker b/tests/docker/dockerfiles/debian-amd64-cross.docker
index 35c593502fc..061cd8e9b82 100644
--- a/tests/docker/dockerfiles/debian-amd64-cross.docker
+++ b/tests/docker/dockerfiles/debian-amd64-cross.docker
@@ -188,4 +188,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-arm64-cross.docker b/tests/docker/dockerfiles/debian-arm64-cross.docker
index d188d538365..3dfa60fdfd7 100644
--- a/tests/docker/dockerfiles/debian-arm64-cross.docker
+++ b/tests/docker/dockerfiles/debian-arm64-cross.docker
@@ -187,4 +187,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-armhf-cross.docker b/tests/docker/dockerfiles/debian-armhf-cross.docker
index 988c87075f6..401c64269c1 100644
--- a/tests/docker/dockerfiles/debian-armhf-cross.docker
+++ b/tests/docker/dockerfiles/debian-armhf-cross.docker
@@ -185,4 +185,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-i686-cross.docker b/tests/docker/dockerfiles/debian-i686-cross.docker
index d720ebb0bca..8b60c7b085f 100644
--- a/tests/docker/dockerfiles/debian-i686-cross.docker
+++ b/tests/docker/dockerfiles/debian-i686-cross.docker
@@ -185,4 +185,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-mips64el-cross.docker b/tests/docker/dockerfiles/debian-mips64el-cross.docker
index d139c10c555..fc83fc0c00b 100644
--- a/tests/docker/dockerfiles/debian-mips64el-cross.docker
+++ b/tests/docker/dockerfiles/debian-mips64el-cross.docker
@@ -183,4 +183,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-mipsel-cross.docker b/tests/docker/dockerfiles/debian-mipsel-cross.docker
index 2cfc33e8249..5f105b1d687 100644
--- a/tests/docker/dockerfiles/debian-mipsel-cross.docker
+++ b/tests/docker/dockerfiles/debian-mipsel-cross.docker
@@ -183,4 +183,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-ppc64el-cross.docker b/tests/docker/dockerfiles/debian-ppc64el-cross.docker
index 7198036380b..2a7e8cba056 100644
--- a/tests/docker/dockerfiles/debian-ppc64el-cross.docker
+++ b/tests/docker/dockerfiles/debian-ppc64el-cross.docker
@@ -186,4 +186,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-riscv64-cross.docker b/tests/docker/dockerfiles/debian-riscv64-cross.docker
index eb49da9781a..349de3a0bbb 100644
--- a/tests/docker/dockerfiles/debian-riscv64-cross.docker
+++ b/tests/docker/dockerfiles/debian-riscv64-cross.docker
@@ -186,4 +186,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian-s390x-cross.docker b/tests/docker/dockerfiles/debian-s390x-cross.docker
index f4c7896a75f..8bc42b1e00b 100644
--- a/tests/docker/dockerfiles/debian-s390x-cross.docker
+++ b/tests/docker/dockerfiles/debian-s390x-cross.docker
@@ -185,4 +185,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/debian.docker b/tests/docker/dockerfiles/debian.docker
index 85b78f7e5f8..ee8b313d654 100644
--- a/tests/docker/dockerfiles/debian.docker
+++ b/tests/docker/dockerfiles/debian.docker
@@ -175,4 +175,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/fedora-rust-nightly.docker b/tests/docker/dockerfiles/fedora-rust-nightly.docker
index 5e88354f133..4f84b803798 100644
--- a/tests/docker/dockerfiles/fedora-rust-nightly.docker
+++ b/tests/docker/dockerfiles/fedora-rust-nightly.docker
@@ -185,4 +185,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker b/tests/docker/dockerfiles/fedora-win64-cross.docker
index 751789e849b..c1e63feb46f 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -120,4 +120,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker
index 393ac0cce73..a6996917c4b 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -162,4 +162,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/tests/docker/dockerfiles/opensuse-leap.docker b/tests/docker/dockerfiles/opensuse-leap.docker
index 4b126b7e7de..fc363c647cd 100644
--- a/tests/docker/dockerfiles/opensuse-leap.docker
+++ b/tests/docker/dockerfiles/opensuse-leap.docker
@@ -149,4 +149,4 @@ ARG UID
 RUN if [ "${USER}" ]; then \
   id ${USER} 2>/dev/null || useradd -u ${UID} -U ${USER}; fi
 
-ENV ENABLE_RUST 1
+ENV ENABLE_RUST=1
diff --git a/scripts/git.orderfile b/scripts/git.orderfile
index 8edac0380ba..4b693c9deec 100644
--- a/scripts/git.orderfile
+++ b/scripts/git.orderfile
@@ -39,3 +39,7 @@ qga/*.json
 # code
 *.c
 *.c.inc
+
+# Generated Dockerfiles
+tests/lcitool/refresh
+tests/docker/dockerfiles/*
-- 
2.47.3