[PATCH v2 0/6] testing/next (meson check-tcg, fedora bump, docs)

[PATCH v2 0/6] testing/next (meson check-tcg, fedora bump, docs)

[Alex Bennée]

Hi,

A few patches dropped off as Thomas merged them. I've added some
additional documentation patches for testing.rst. I guess I'll wrap
this up into a PR later this week. The docs patches need review:

 - docs/devel: add forward reference to check-tcg
 - docs/devel: update the container based tests
 - docs/devel: expand on use of containers to build tests

Alex Bennée (5):
  meson.build: expose TCG cross compiler information in summary
  tests/acceptance: allow a "graceful" failing for virtio-gpu test
  docs/devel: expand on use of containers to build tests
  docs/devel: update the container based tests
  docs/devel: add forward reference to check-tcg

Philippe Mathieu-Daudé (1):
  docker: Bump Fedora images to release 33

 docs/devel/testing.rst                        | 85 ++++++++++++++-----
 meson.build                                   | 18 ++++
 tests/acceptance/virtio-gpu.py                |  7 +-
 .../dockerfiles/fedora-cris-cross.docker      |  2 +-
 .../dockerfiles/fedora-i386-cross.docker      |  2 +-
 .../dockerfiles/fedora-win32-cross.docker     |  2 +-
 .../dockerfiles/fedora-win64-cross.docker     |  2 +-
 tests/docker/dockerfiles/fedora.docker        |  2 +-
 tests/tcg/configure.sh                        |  8 --
 9 files changed, 93 insertions(+), 35 deletions(-)

-- 
2.20.1

[PATCH v2 1/6] meson.build: expose TCG cross compiler information in summary

[Alex Bennée]

Blink and you miss the cross TCG compiler stuff so lets display it
with the rest of the compiler information.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210216102522.6279-1-alex.bennee@linaro.org>
Message-Id: <20210217121932.19986-2-alex.bennee@linaro.org>
---
 meson.build            | 18 ++++++++++++++++++
 tests/tcg/configure.sh |  8 --------
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/meson.build b/meson.build
index 05a67c20d9..f3db83e974 100644
--- a/meson.build
+++ b/meson.build
@@ -2509,6 +2509,24 @@ endif
 summary_info += {'strip binaries':    get_option('strip')}
 summary_info += {'sparse':            sparse.found() ? sparse.full_path() : false}
 summary_info += {'mingw32 support':   targetos == 'windows'}
+
+# snarf the cross-compilation information for tests
+foreach target: target_dirs
+  tcg_mak = meson.current_build_dir() / 'tests/tcg' / 'config-' + target + '.mak'
+  if fs.exists(tcg_mak)
+    config_cross_tcg = keyval.load(tcg_mak)
+    target = config_cross_tcg['TARGET_NAME']
+    compiler = ''
+    if 'DOCKER_CROSS_CC_GUEST' in config_cross_tcg
+      summary_info += {target + ' tests': config_cross_tcg['DOCKER_CROSS_CC_GUEST'] +
+                                          ' via ' + config_cross_tcg['DOCKER_IMAGE']}
+    elif 'CROSS_CC_GUEST' in config_cross_tcg
+      summary_info += {target + ' tests'
+                                : config_cross_tcg['CROSS_CC_GUEST'] }
+    endif
+   endif
+endforeach
+
 summary(summary_info, bool_yn: true, section: 'Compilation')
 
 # Targets and accelerators
diff --git a/tests/tcg/configure.sh b/tests/tcg/configure.sh
index 551c02f469..36b8a73a54 100755
--- a/tests/tcg/configure.sh
+++ b/tests/tcg/configure.sh
@@ -263,11 +263,3 @@ for target in $target_list; do
     echo "DOCKER_CROSS_CC_GUEST=$container_cross_cc" >> $config_target_mak
   fi
 done
-
-# report container support state
-echo "cross containers  $container"
-
-if test -n "$enabled_cross_compilers"; then
-    echo
-    echo "NOTE: guest cross-compilers enabled:$enabled_cross_compilers"
-fi
-- 
2.20.1

[PATCH v2 2/6] docker: Bump Fedora images to release 33

[Alex Bennée]

From: Philippe Mathieu-Daudé <philmd@redhat.com>

Fedora 33 was released on October 27, 2020.

Update all the Fedora 32 images to this new release.

Suggested-by: Daniel Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210118181255.314672-1-philmd@redhat.com>
Message-Id: <20210217121932.19986-5-alex.bennee@linaro.org>
---
 tests/docker/dockerfiles/fedora-cris-cross.docker  | 2 +-
 tests/docker/dockerfiles/fedora-i386-cross.docker  | 2 +-
 tests/docker/dockerfiles/fedora-win32-cross.docker | 2 +-
 tests/docker/dockerfiles/fedora-win64-cross.docker | 2 +-
 tests/docker/dockerfiles/fedora.docker             | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/docker/dockerfiles/fedora-cris-cross.docker b/tests/docker/dockerfiles/fedora-cris-cross.docker
index 09e7e449f9..1dfff6e0b9 100644
--- a/tests/docker/dockerfiles/fedora-cris-cross.docker
+++ b/tests/docker/dockerfiles/fedora-cris-cross.docker
@@ -2,7 +2,7 @@
 # Cross compiler for cris system tests
 #
 
-FROM fedora:30
+FROM fedora:33
 ENV PACKAGES gcc-cris-linux-gnu
 RUN dnf install -y $PACKAGES
 RUN rpm -q $PACKAGES | sort > /packages.txt
diff --git a/tests/docker/dockerfiles/fedora-i386-cross.docker b/tests/docker/dockerfiles/fedora-i386-cross.docker
index a6e411291b..966072c08e 100644
--- a/tests/docker/dockerfiles/fedora-i386-cross.docker
+++ b/tests/docker/dockerfiles/fedora-i386-cross.docker
@@ -1,4 +1,4 @@
-FROM fedora:31
+FROM fedora:33
 ENV PACKAGES \
     bzip2 \
     diffutils \
diff --git a/tests/docker/dockerfiles/fedora-win32-cross.docker b/tests/docker/dockerfiles/fedora-win32-cross.docker
index 087df598a0..81b5659e9c 100644
--- a/tests/docker/dockerfiles/fedora-win32-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win32-cross.docker
@@ -1,4 +1,4 @@
-FROM fedora:32
+FROM fedora:33
 
 # Please keep this list sorted alphabetically
 ENV PACKAGES \
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker b/tests/docker/dockerfiles/fedora-win64-cross.docker
index d5d2f5f00d..bcb428e724 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -1,4 +1,4 @@
-FROM fedora:32
+FROM fedora:33
 
 # Please keep this list sorted alphabetically
 ENV PACKAGES \
diff --git a/tests/docker/dockerfiles/fedora.docker b/tests/docker/dockerfiles/fedora.docker
index 0d7602abbe..915fdc1845 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,4 +1,4 @@
-FROM fedora:32
+FROM fedora:33
 
 # Please keep this list sorted alphabetically
 ENV PACKAGES \
-- 
2.20.1

[PATCH v2 3/6] tests/acceptance: allow a "graceful" failing for virtio-gpu test

[Alex Bennée]

This is a band-aid with a TODO for cases when QEMU doesn't start due
to missing VirGL. Longer term we could do with some proper feature
probing.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210217121932.19986-7-alex.bennee@linaro.org>
---
 tests/acceptance/virtio-gpu.py | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
index ab1a4c1a71..ab18cddbb7 100644
--- a/tests/acceptance/virtio-gpu.py
+++ b/tests/acceptance/virtio-gpu.py
@@ -85,7 +85,12 @@ def test_virtio_vga_virgl(self):
             "-append",
             kernel_command_line,
         )
-        self.vm.launch()
+        try:
+            self.vm.launch()
+        except:
+            # TODO: probably fails because we are missing the VirGL features
+            self.cancel("VirGL not enabled?")
+
         self.wait_for_console_pattern("as init process")
         exec_command_and_wait_for_pattern(
             self, "/usr/sbin/modprobe virtio_gpu", ""
-- 
2.20.1

Probing Meson for build configurations (was: [PATCH v2 3/6] tests/acceptance: allow a "graceful" failing for virtio-gpu test)

[Wainer dos Santos Moschetta]

Hi Paolo,

Last week I was chatting with Cleber about probing configured features 
so that tests could be skipped (just like on this case). He has a 
implementation which never landed in, and is based on the old build 
system. Now with Meson, I am wondering if it has some sort of API for 
probing, or parsing the JSON files in build/meson-info/ is the proper 
way to inspect the build configuration.

Thanks!

- Wainer

On 2/22/21 7:14 AM, Alex Bennée wrote:
> This is a band-aid with a TODO for cases when QEMU doesn't start due
> to missing VirGL. Longer term we could do with some proper feature
> probing.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> Reviewed-by: Willian Rampazzo <willianr@redhat.com>
> Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> Message-Id: <20210217121932.19986-7-alex.bennee@linaro.org>
> ---
>   tests/acceptance/virtio-gpu.py | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
> index ab1a4c1a71..ab18cddbb7 100644
> --- a/tests/acceptance/virtio-gpu.py
> +++ b/tests/acceptance/virtio-gpu.py
> @@ -85,7 +85,12 @@ def test_virtio_vga_virgl(self):
>               "-append",
>               kernel_command_line,
>           )
> -        self.vm.launch()
> +        try:
> +            self.vm.launch()
> +        except:
> +            # TODO: probably fails because we are missing the VirGL features
> +            self.cancel("VirGL not enabled?")
> +
>           self.wait_for_console_pattern("as init process")
>           exec_command_and_wait_for_pattern(
>               self, "/usr/sbin/modprobe virtio_gpu", ""

Re: Probing Meson for build configurations (was: [PATCH v2 3/6] tests/acceptance: allow a "graceful" failing for virtio-gpu test)

[Daniel P. Berrangé]

On Mon, Feb 22, 2021 at 12:44:37PM -0300, Wainer dos Santos Moschetta wrote:
> Hi Paolo,
> 
> Last week I was chatting with Cleber about probing configured features so
> that tests could be skipped (just like on this case). He has a
> implementation which never landed in, and is based on the old build system.
> Now with Meson, I am wondering if it has some sort of API for probing, or
> parsing the JSON files in build/meson-info/ is the proper way to inspect the
> build configuration.

Probing build configuration is the wrong approach.

We need to be querying the QEMU binary to ask if it has the logical
feature we need.  In this case

{
  "execute": "device-list-properties",
  "arguments": {
    "typename": "virtio-gpu-pci"
  },
}


the response will include "virgl" property, if QEMU was compiled
with VirGL. This is how libvirt detects VirGL support in QEMU
today.

> On 2/22/21 7:14 AM, Alex Bennée wrote:
> > This is a band-aid with a TODO for cases when QEMU doesn't start due
> > to missing VirGL. Longer term we could do with some proper feature
> > probing.
> > 
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Reviewed-by: Willian Rampazzo <willianr@redhat.com>
> > Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Message-Id: <20210217121932.19986-7-alex.bennee@linaro.org>
> > ---
> >   tests/acceptance/virtio-gpu.py | 7 ++++++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
> > index ab1a4c1a71..ab18cddbb7 100644
> > --- a/tests/acceptance/virtio-gpu.py
> > +++ b/tests/acceptance/virtio-gpu.py
> > @@ -85,7 +85,12 @@ def test_virtio_vga_virgl(self):
> >               "-append",
> >               kernel_command_line,
> >           )
> > -        self.vm.launch()
> > +        try:
> > +            self.vm.launch()
> > +        except:
> > +            # TODO: probably fails because we are missing the VirGL features
> > +            self.cancel("VirGL not enabled?")
> > +
> >           self.wait_for_console_pattern("as init process")
> >           exec_command_and_wait_for_pattern(
> >               self, "/usr/sbin/modprobe virtio_gpu", ""

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[PATCH v2 4/6] docs/devel: expand on use of containers to build tests

[Alex Bennée]

Expand on the usage of containers for building tests and why we have
some that are not used to build QEMU itself.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>
---
 docs/devel/testing.rst | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 00ce16de48..488d4e3537 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -272,10 +272,10 @@ Note that the following group names have a special meaning:
 
 - disabled: Tests in this group are disabled and ignored by check.
 
-.. _docker-ref:
+.. _container-ref:
 
-Docker based tests
-==================
+Container based tests
+=====================
 
 Introduction
 ------------
@@ -1001,10 +1001,17 @@ for the architecture in question, for example::
 There is also a ``--cross-cc-flags-ARCH`` flag in case additional
 compiler flags are needed to build for a given target.
 
-If you have the ability to run containers as the user you can also
-take advantage of the build systems "Docker" support. It will then use
-containers to build any test case for an enabled guest where there is
-no system compiler available. See :ref:`docker-ref` for details.
+If you have the ability to run containers as the user the build system
+will automatically use them where no system compiler is available. For
+architectures where we also support building QEMU we will generally
+use the same container to build tests. However there are a number of
+additional containers defined that have a minimal cross-build
+environment that is only suitable for building test cases. Sometimes
+we may use a bleeding edge distribution for compiler features needed
+for test cases that aren't yet in the LTS distros we support for QEMU
+itself.
+
+See :ref:`container-ref` for more details.
 
 Running subset of tests
 -----------------------
-- 
2.20.1

Re: [PATCH v2 4/6] docs/devel: expand on use of containers to build tests

[Thomas Huth]

On 22/02/2021 11.14, Alex Bennée wrote:
> Expand on the usage of containers for building tests and why we have
> some that are not used to build QEMU itself.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Thomas Huth <thuth@redhat.com>
> ---
>   docs/devel/testing.rst | 21 ++++++++++++++-------
>   1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
> index 00ce16de48..488d4e3537 100644
> --- a/docs/devel/testing.rst
> +++ b/docs/devel/testing.rst
> @@ -272,10 +272,10 @@ Note that the following group names have a special meaning:
>   
>   - disabled: Tests in this group are disabled and ignored by check.
>   
> -.. _docker-ref:
> +.. _container-ref:
>   
> -Docker based tests
> -==================
> +Container based tests
> +=====================
>   
>   Introduction
>   ------------
> @@ -1001,10 +1001,17 @@ for the architecture in question, for example::
>   There is also a ``--cross-cc-flags-ARCH`` flag in case additional
>   compiler flags are needed to build for a given target.
>   
> -If you have the ability to run containers as the user you can also
> -take advantage of the build systems "Docker" support. It will then use
> -containers to build any test case for an enabled guest where there is
> -no system compiler available. See :ref:`docker-ref` for details.
> +If you have the ability to run containers as the user the build system
> +will automatically use them where no system compiler is available. For
> +architectures where we also support building QEMU we will generally
> +use the same container to build tests. However there are a number of
> +additional containers defined that have a minimal cross-build
> +environment that is only suitable for building test cases. Sometimes
> +we may use a bleeding edge distribution for compiler features needed
> +for test cases that aren't yet in the LTS distros we support for QEMU
> +itself.
> +
> +See :ref:`container-ref` for more details.
>   
>   Running subset of tests
>   -----------------------
> 

Reviewed-by: Thomas Huth <thuth@redhat.com>

[PATCH v2 5/6] docs/devel: update the container based tests

[Alex Bennée]

This section has grown a little stale so clean-up the language and
examples for current usage:

  - refer to containers at the top
  - mention podman can also be used
  - add podman prerequisites section
  - move to using "docker-help" for online help
  - mention the registry and it's purpose
  - don't refer to out-of-date min-glib image

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>
---
 docs/devel/testing.rst | 61 +++++++++++++++++++++++++++++++-----------
 1 file changed, 46 insertions(+), 15 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 488d4e3537..e43c992f21 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -280,13 +280,17 @@ Container based tests
 Introduction
 ------------
 
-The Docker testing framework in QEMU utilizes public Docker images to build and
-test QEMU in predefined and widely accessible Linux environments.  This makes
-it possible to expand the test coverage across distros, toolchain flavors and
-library versions.
-
-Prerequisites
--------------
+The container testing framework in QEMU utilizes public images to
+build and test QEMU in predefined and widely accessible Linux
+environments. This makes it possible to expand the test coverage
+across distros, toolchain flavors and library versions. The support
+was originally written for Docker although we also support Podman as
+an alternative container runtime. Although the many of the target
+names and scripts are prefixed with "docker" the system will
+automatically run on whichever is configured.
+
+Docker Prerequisites
+--------------------
 
 Install "docker" with the system package manager and start the Docker service
 on your development machine, then make sure you have the privilege to run
@@ -316,26 +320,53 @@ Note that any one of above configurations makes it possible for the user to
 exploit the whole host with Docker bind mounting or other privileged
 operations.  So only do it on development machines.
 
+Podman Prerequisites
+--------------------
+
+Install "podman" with the system package manager.
+
+.. code::
+
+  $ sudo dnf install podman
+  $ podman ps
+
+The last command should print an empty table, to verify the system is ready.
+
 Quickstart
 ----------
 
-From source tree, type ``make docker`` to see the help. Testing can be started
-without configuring or building QEMU (``configure`` and ``make`` are done in
-the container, with parameters defined by the make target):
+From source tree, type ``make docker-help`` to see the help. Testing
+can be started without configuring or building QEMU (``configure`` and
+``make`` are done in the container, with parameters defined by the
+make target):
 
 .. code::
 
-  make docker-test-build@min-glib
+  make docker-test-build@centos7
 
-This will create a container instance using the ``min-glib`` image (the image
+This will create a container instance using the ``centos7`` image (the image
 is downloaded and initialized automatically), in which the ``test-build`` job
 is executed.
 
+Registry
+--------
+
+The QEMU project has a container registry hosted by GitLab at
+``registry.gitlab.com/qemu-project/qemu`` which will automatically be
+used to pull in pre-built layers. This avoids unnecessary strain on
+the distro archives created by multiple developers running the same
+container build steps over and over again. This can be overridden
+locally by using the ``NOCACHE`` build option:
+
+.. code::
+
+   make docker-image-debian10 NOCACHE=1
+
 Images
 ------
 
-Along with many other images, the ``min-glib`` image is defined in a Dockerfile
-in ``tests/docker/dockerfiles/``, called ``min-glib.docker``. ``make docker``
+Along with many other images, the ``centos7`` image is defined in a Dockerfile
+in ``tests/docker/dockerfiles/``, called ``centos7.docker``. ``make docker-help``
 command will list all the available images.
 
 To add a new image, simply create a new ``.docker`` file under the
@@ -355,7 +386,7 @@ QEMU.  Docker tests are the executables under ``tests/docker`` named
 library, ``tests/docker/common.rc``, which provides helpers to find the QEMU
 source and build it.
 
-The full list of tests is printed in the ``make docker`` help.
+The full list of tests is printed in the ``make docker-help`` help.
 
 Debugging a Docker test failure
 -------------------------------
-- 
2.20.1

Re: [PATCH v2 5/6] docs/devel: update the container based tests

[Thomas Huth]

On 22/02/2021 11.14, Alex Bennée wrote:
> This section has grown a little stale so clean-up the language and
> examples for current usage:
> 
>    - refer to containers at the top
>    - mention podman can also be used
>    - add podman prerequisites section
>    - move to using "docker-help" for online help
>    - mention the registry and it's purpose
>    - don't refer to out-of-date min-glib image
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Thomas Huth <thuth@redhat.com>
> ---
>   docs/devel/testing.rst | 61 +++++++++++++++++++++++++++++++-----------
>   1 file changed, 46 insertions(+), 15 deletions(-)
[...]
>   .. code::
>   
> -  make docker-test-build@min-glib
> +  make docker-test-build@centos7
>   
> -This will create a container instance using the ``min-glib`` image (the image
> +This will create a container instance using the ``centos7`` image (the image
>   is downloaded and initialized automatically), in which the ``test-build`` job
>   is executed.

We're going to drop support for CentOS 7 in three months (May) ... so maybe 
it makes more sense to directly use centos8 or another long-term distro here?

> +Registry
> +--------
> +
> +The QEMU project has a container registry hosted by GitLab at
> +``registry.gitlab.com/qemu-project/qemu`` which will automatically be
> +used to pull in pre-built layers. This avoids unnecessary strain on
> +the distro archives created by multiple developers running the same
> +container build steps over and over again. This can be overridden
> +locally by using the ``NOCACHE`` build option:

Thanks a lot for adding the information!

  Thomas

Re: [PATCH v2 5/6] docs/devel: update the container based tests

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 22/02/2021 11.14, Alex Bennée wrote:
>> This section has grown a little stale so clean-up the language and
>> examples for current usage:
>> 
>>    - refer to containers at the top
>>    - mention podman can also be used
>>    - add podman prerequisites section
>>    - move to using "docker-help" for online help
>>    - mention the registry and it's purpose
>>    - don't refer to out-of-date min-glib image
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Thomas Huth <thuth@redhat.com>
>> ---
>>   docs/devel/testing.rst | 61 +++++++++++++++++++++++++++++++-----------
>>   1 file changed, 46 insertions(+), 15 deletions(-)
> [...]
>>   .. code::
>>   
>> -  make docker-test-build@min-glib
>> +  make docker-test-build@centos7
>>   
>> -This will create a container instance using the ``min-glib`` image (the image
>> +This will create a container instance using the ``centos7`` image (the image
>>   is downloaded and initialized automatically), in which the ``test-build`` job
>>   is executed.
>
> We're going to drop support for CentOS 7 in three months (May) ... so maybe 
> it makes more sense to directly use centos8 or another long-term distro here?
>
>> +Registry
>> +--------
>> +
>> +The QEMU project has a container registry hosted by GitLab at
>> +``registry.gitlab.com/qemu-project/qemu`` which will automatically be
>> +used to pull in pre-built layers. This avoids unnecessary strain on
>> +the distro archives created by multiple developers running the same
>> +container build steps over and over again. This can be overridden
>> +locally by using the ``NOCACHE`` build option:
>
> Thanks a lot for adding the information!
>
>   Thomas

Is that a r-b if I change to centos8?

-- 
Alex Bennée

Re: [PATCH v2 5/6] docs/devel: update the container based tests

[Thomas Huth]

On 22/02/2021 13.14, Alex Bennée wrote:
> 
> Thomas Huth <thuth@redhat.com> writes:
> 
>> On 22/02/2021 11.14, Alex Bennée wrote:
>>> This section has grown a little stale so clean-up the language and
>>> examples for current usage:
>>>
>>>     - refer to containers at the top
>>>     - mention podman can also be used
>>>     - add podman prerequisites section
>>>     - move to using "docker-help" for online help
>>>     - mention the registry and it's purpose
>>>     - don't refer to out-of-date min-glib image
>>>
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> Cc: Thomas Huth <thuth@redhat.com>
>>> ---
>>>    docs/devel/testing.rst | 61 +++++++++++++++++++++++++++++++-----------
>>>    1 file changed, 46 insertions(+), 15 deletions(-)
>> [...]
>>>    .. code::
>>>    
>>> -  make docker-test-build@min-glib
>>> +  make docker-test-build@centos7
>>>    
>>> -This will create a container instance using the ``min-glib`` image (the image
>>> +This will create a container instance using the ``centos7`` image (the image
>>>    is downloaded and initialized automatically), in which the ``test-build`` job
>>>    is executed.
>>
>> We're going to drop support for CentOS 7 in three months (May) ... so maybe
>> it makes more sense to directly use centos8 or another long-term distro here?
>>
>>> +Registry
>>> +--------
>>> +
>>> +The QEMU project has a container registry hosted by GitLab at
>>> +``registry.gitlab.com/qemu-project/qemu`` which will automatically be
>>> +used to pull in pre-built layers. This avoids unnecessary strain on
>>> +the distro archives created by multiple developers running the same
>>> +container build steps over and over again. This can be overridden
>>> +locally by using the ``NOCACHE`` build option:
>>
>> Thanks a lot for adding the information!
>>
>>    Thomas
> 
> Is that a r-b if I change to centos8?

At least now it is:

Reviewed-by: Thomas Huth <thuth@redhat.com>

[PATCH v2 6/6] docs/devel: add forward reference to check-tcg

[Alex Bennée]

For completeness reference the check-tcg tests in the container
preamble text.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>
---
 docs/devel/testing.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index e43c992f21..3124ee2470 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -289,6 +289,9 @@ an alternative container runtime. Although the many of the target
 names and scripts are prefixed with "docker" the system will
 automatically run on whichever is configured.
 
+The container images are also used to augment the generation of tests
+for testing TCG. See :ref:`checktcg-ref` for more details.
+
 Docker Prerequisites
 --------------------
 
@@ -1011,6 +1014,8 @@ And remove any package you want with::
 If you've used ``make check-acceptance``, the Python virtual environment where
 Avocado is installed will be cleaned up as part of ``make check-clean``.
 
+.. _checktcg-ref:
+
 Testing with "make check-tcg"
 =============================
 
-- 
2.20.1

Re: [PATCH v2 6/6] docs/devel: add forward reference to check-tcg

[Philippe Mathieu-Daudé]

On 2/22/21 11:14 AM, Alex Bennée wrote:
> For completeness reference the check-tcg tests in the container
> preamble text.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Thomas Huth <thuth@redhat.com>
> ---
>  docs/devel/testing.rst | 5 +++++
>  1 file changed, 5 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Re: [PATCH v2 6/6] docs/devel: add forward reference to check-tcg

[Thomas Huth]

On 22/02/2021 11.14, Alex Bennée wrote:
> For completeness reference the check-tcg tests in the container
> preamble text.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Thomas Huth <thuth@redhat.com>
> ---
>   docs/devel/testing.rst | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
> index e43c992f21..3124ee2470 100644
> --- a/docs/devel/testing.rst
> +++ b/docs/devel/testing.rst
> @@ -289,6 +289,9 @@ an alternative container runtime. Although the many of the target
>   names and scripts are prefixed with "docker" the system will
>   automatically run on whichever is configured.
>   
> +The container images are also used to augment the generation of tests
> +for testing TCG. See :ref:`checktcg-ref` for more details.
> +
>   Docker Prerequisites
>   --------------------
>   
> @@ -1011,6 +1014,8 @@ And remove any package you want with::
>   If you've used ``make check-acceptance``, the Python virtual environment where
>   Avocado is installed will be cleaned up as part of ``make check-clean``.
>   
> +.. _checktcg-ref:
> +
>   Testing with "make check-tcg"
>   =============================
>   
> 

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH v2 0/6] testing/next (meson check-tcg, fedora bump, docs)

[Richard Henderson]

On 2/22/21 2:14 AM, Alex Bennée wrote:
> Alex Bennée (5):
>   meson.build: expose TCG cross compiler information in summary
>   tests/acceptance: allow a "graceful" failing for virtio-gpu test
>   docs/devel: expand on use of containers to build tests
>   docs/devel: update the container based tests
>   docs/devel: add forward reference to check-tcg
> 
> Philippe Mathieu-Daudé (1):
>   docker: Bump Fedora images to release 33

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

r~