It's becoming harder to maintain a cross-compiler to test this host
architecture as the old stable Debian 10 ("Buster") moved into LTS
which supports fewer architectures. For now:

  - mark it's deprecation in the docs
  - downgrade the containers to build TCG tests only
  - drop the cross builds from our CI

Users with an appropriate toolchain and user-space can still take
their chances building it.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Huacai Chen <chenhuacai@kernel.org>
Message-Id: <20220826172128.353798-16-alex.bennee@linaro.org>

---
v2
  - explicit little endian instead of LE
  - s/A/As/
  - restore mips to dockerfile
---
 docs/about/build-platforms.rst                |  2 +-
 docs/about/deprecated.rst                     | 13 +++++++
 .gitlab-ci.d/container-cross.yml              |  1 -
 .gitlab-ci.d/crossbuilds.yml                  | 14 -------
 tests/docker/Makefile.include                 |  5 +--
 .../dockerfiles/debian-mips-cross.docker      | 38 +++++--------------
 6 files changed, 26 insertions(+), 47 deletions(-)

diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index a2fee53248..1c1e7b9e11 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -41,7 +41,7 @@ Those hosts are officially supported, with various accelerators:
      - Accelerators
    * - Arm
      - kvm (64 bit only), tcg, xen
-   * - MIPS
+   * - MIPS (little endian only)
      - kvm, tcg
    * - PPC
      - kvm, tcg
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index c75a25daad..0d1fd4469b 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -213,6 +213,19 @@ MIPS ``Trap-and-Emul`` KVM support (since 6.0)
 The MIPS ``Trap-and-Emul`` KVM host and guest support has been removed
 from Linux upstream kernel, declare it deprecated.
 
+Host Architectures
+------------------
+
+BE MIPS (since 7.2)
+'''''''''''''''''''
+
+As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of
+MIPS moved out of support making it hard to maintain our
+cross-compilation CI tests of the architecture. As we no longer have
+CI coverage support may bitrot away before the deprecation process
+completes. The little endian variants of MIPS (both 32 and 64 bit) are
+still a supported host architecture.
+
 QEMU API (QAPI) events
 ----------------------
 
diff --git a/.gitlab-ci.d/container-cross.yml b/.gitlab-ci.d/container-cross.yml
index 611c6c0b39..95d57e1c5d 100644
--- a/.gitlab-ci.d/container-cross.yml
+++ b/.gitlab-ci.d/container-cross.yml
@@ -89,7 +89,6 @@ mips64el-debian-cross-container:
 mips-debian-cross-container:
   extends: .container_job_template
   stage: containers
-  needs: ['amd64-debian10-container']
   variables:
     NAME: debian-mips-cross
 
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml
index 4a5fb6ea2a..c4cd96433d 100644
--- a/.gitlab-ci.d/crossbuilds.yml
+++ b/.gitlab-ci.d/crossbuilds.yml
@@ -70,20 +70,6 @@ cross-i386-tci:
     EXTRA_CONFIGURE_OPTS: --target-list=i386-softmmu,i386-linux-user,aarch64-softmmu,aarch64-linux-user,ppc-softmmu,ppc-linux-user
     MAKE_CHECK_ARGS: check check-tcg
 
-cross-mips-system:
-  extends: .cross_system_build_job
-  needs:
-    job: mips-debian-cross-container
-  variables:
-    IMAGE: debian-mips-cross
-
-cross-mips-user:
-  extends: .cross_user_build_job
-  needs:
-    job: mips-debian-cross-container
-  variables:
-    IMAGE: debian-mips-cross
-
 cross-mipsel-system:
   extends: .cross_system_build_job
   needs:
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index c3375f89c5..b1bf56434f 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -81,14 +81,12 @@ endif
 
 # For non-x86 hosts not all cross-compilers have been packaged
 ifneq ($(HOST_ARCH),x86_64)
-DOCKER_PARTIAL_IMAGES += debian-mips-cross debian-mipsel-cross debian-mips64el-cross
+DOCKER_PARTIAL_IMAGES += debian-mipsel-cross debian-mips64el-cross
 DOCKER_PARTIAL_IMAGES += debian-ppc64el-cross
 DOCKER_PARTIAL_IMAGES += debian-s390x-cross
 DOCKER_PARTIAL_IMAGES += fedora
 endif
 
-docker-image-debian-mips-cross: docker-image-debian10
-
 # The native build should never use the registry
 docker-image-debian-native: DOCKER_REGISTRY=
 
@@ -144,6 +142,7 @@ DOCKER_PARTIAL_IMAGES += debian-hppa-cross
 DOCKER_PARTIAL_IMAGES += debian-loongarch-cross
 DOCKER_PARTIAL_IMAGES += debian-m68k-cross debian-mips64-cross
 DOCKER_PARTIAL_IMAGES += debian-microblaze-cross
+DOCKER_PARTIAL_IMAGES += debian-mips-cross
 DOCKER_PARTIAL_IMAGES += debian-nios2-cross
 DOCKER_PARTIAL_IMAGES += debian-riscv64-test-cross
 DOCKER_PARTIAL_IMAGES += debian-sh4-cross debian-sparc64-cross
diff --git a/tests/docker/dockerfiles/debian-mips-cross.docker b/tests/docker/dockerfiles/debian-mips-cross.docker
index 26c154014d..7b55f0f3b2 100644
--- a/tests/docker/dockerfiles/debian-mips-cross.docker
+++ b/tests/docker/dockerfiles/debian-mips-cross.docker
@@ -1,32 +1,14 @@
 #
 # Docker mips cross-compiler target
 #
-# This docker target builds on the debian Buster base image.
+# This docker target builds on the Debian Bullseye base image.
 #
-FROM qemu/debian10
-
-MAINTAINER Philippe Mathieu-Daudé <f4bug@amsat.org>
-
-# Add the foreign architecture we want and install dependencies
-RUN dpkg --add-architecture mips
-RUN apt update && \
-    DEBIAN_FRONTEND=noninteractive eatmydata \
-    apt install -y --no-install-recommends \
-        gcc-mips-linux-gnu
-
-RUN apt update && \
-    DEBIAN_FRONTEND=noninteractive eatmydata \
-    apt build-dep -yy -a mips --arch-only qemu
-
-# Specify the cross prefix for this image (see tests/docker/common.rc)
-ENV QEMU_CONFIGURE_OPTS --cross-prefix=mips-linux-gnu-
-ENV DEF_TARGET_LIST mips-softmmu,mipsel-linux-user
-
-# Install extra libraries to increase code coverage
-RUN apt update && \
-    DEBIAN_FRONTEND=noninteractive eatmydata \
-    apt install -y --no-install-recommends \
-        libbz2-dev:mips \
-        liblzo2-dev:mips \
-        librdmacm-dev:mips \
-        libsnappy-dev:mips
+FROM docker.io/library/debian:11-slim
+
+RUN export DEBIAN_FRONTEND=noninteractive && \
+    apt-get update && \
+    apt-get install -y eatmydata && \
+    eatmydata apt-get dist-upgrade -y && \
+    eatmydata apt-get install --no-install-recommends -y \
+            gcc-mips-linux-gnu \
+            libc6-dev-mips-cross
-- 
2.34.1

On 9/14/22 16:59, Alex Bennée wrote:
> It's becoming harder to maintain a cross-compiler to test this host
> architecture as the old stable Debian 10 ("Buster") moved into LTS
> which supports fewer architectures. For now:
> 
>    - mark it's deprecation in the docs
>    - downgrade the containers to build TCG tests only
>    - drop the cross builds from our CI
> 
> Users with an appropriate toolchain and user-space can still take
> their chances building it.
> 
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> Reviewed-by: Philippe Mathieu-Daudé<f4bug@amsat.org>
> Reviewed-by: Huacai Chen<chenhuacai@kernel.org>
> Message-Id:<20220826172128.353798-16-alex.bennee@linaro.org>
> 
> ---
> v2
>    - explicit little endian instead of LE
>    - s/A/As/
>    - restore mips to dockerfile
> ---
>   docs/about/build-platforms.rst                |  2 +-
>   docs/about/deprecated.rst                     | 13 +++++++
>   .gitlab-ci.d/container-cross.yml              |  1 -
>   .gitlab-ci.d/crossbuilds.yml                  | 14 -------
>   tests/docker/Makefile.include                 |  5 +--
>   .../dockerfiles/debian-mips-cross.docker      | 38 +++++--------------
>   6 files changed, 26 insertions(+), 47 deletions(-)

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


r~

   I am using gcc230 machine for the gcc compile farm.

   This is a big endian mips64 machine runnig Debian Buster.

When compiling the qemu 7.1.0 release source,
the generated binaries are 32-bit mips binaries,
and I did not find out how to generate a 64-bit versions
of the executables.

   As mips32 seems to still be the default arch that gcc uses,
I don't really understand the idea of depreciating big endian mips32.

Is this solely related to cross-compilation issues?

Pierre Muller


More information on gcc230:
muller@gcc230:~$ uname -a
Linux gcc230 4.9.79-UBNT_E300 #9 SMP Tue Jul 13 13:04:47 BST 2021 mips64 GNU/Linux
muller@gcc230:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
muller@gcc230:~$ gcc --version
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

muller@gcc230:~$ gcc -print-libgcc-file-name
/usr/lib/gcc/mips-linux-gnu/8/libgcc.a
muller@gcc230:~$ gcc -mabi=64 -print-libgcc-file-name
/usr/lib/gcc/mips-linux-gnu/8/64/libgcc.a

Pierre Muller <pierre@freepascal.org> writes:

>   I am using gcc230 machine for the gcc compile farm.
>
>   This is a big endian mips64 machine runnig Debian Buster.

That's still oldstable, the current release of Debian doesn't support BE
mips in either 32 or 64 bit. As bullseye was released last year buster
will drop out of QEMU support window by August 2023 at the latest
(current LTS + 2 years or upstream drops support whichever comes first).

> When compiling the qemu 7.1.0 release source,
> the generated binaries are 32-bit mips binaries,
> and I did not find out how to generate a 64-bit versions
> of the executables.

I don't think we've ever been able to cross build QEMU BE mips64 - it was
only with buster we stopped relying on sid for access to working cross
compilers for building TCG tests:

  4575a701ea (tests/docker: move our mips64 cross compile to Buster)

>   As mips32 seems to still be the default arch that gcc uses,
> I don't really understand the idea of depreciating big endian mips32.
>
> Is this solely related to cross-compilation issues?

Decent cross-compilation support for building QEMU is the minimum we
need to ensure things don't bitrot. Ideally we would have real HW
running a non-bespoke OS with a gitlab runner so we could build *and*
run tests. However finding such HW is even harder than keeping the cross
compilation working.

>
> Pierre Muller
>
>
> More information on gcc230:
> muller@gcc230:~$ uname -a
> Linux gcc230 4.9.79-UBNT_E300 #9 SMP Tue Jul 13 13:04:47 BST 2021 mips64 GNU/Linux
> muller@gcc230:~$ cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> NAME="Debian GNU/Linux"
> VERSION_ID="10"
> VERSION="10 (buster)"
> VERSION_CODENAME=buster
> ID=debian
> HOME_URL="https://www.debian.org/"
> SUPPORT_URL="https://www.debian.org/support"
> BUG_REPORT_URL="https://bugs.debian.org/"
> muller@gcc230:~$ gcc --version
> gcc (Debian 8.3.0-6) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> muller@gcc230:~$ gcc -print-libgcc-file-name
> /usr/lib/gcc/mips-linux-gnu/8/libgcc.a
> muller@gcc230:~$ gcc -mabi=64 -print-libgcc-file-name
> /usr/lib/gcc/mips-linux-gnu/8/64/libgcc.a


-- 
Alex Bennée

On 9/16/22 10:08, Pierre Muller wrote:
> 
>    I am using gcc230 machine for the gcc compile farm.
> 
>    This is a big endian mips64 machine runnig Debian Buster.
> 
> When compiling the qemu 7.1.0 release source,
> the generated binaries are 32-bit mips binaries,
> and I did not find out how to generate a 64-bit versions
> of the executables.

Yes, that host seems to have been installed with the o32 abi instead of the n64 (or n32) abi.

>    As mips32 seems to still be the default arch that gcc uses,
> I don't really understand the idea of depreciating big endian mips32.
> 
> Is this solely related to cross-compilation issues?

Yes.  Even gcc230 is fairly small for actually compiling qemu, it takes many hours.  So 
for many hosts we rely on cross-compilation from x86_64.

For that, we rely on the set of cross-compilers built by Debian 11 (bullseye) plus (!) the 
host libraries for that platform.  We cannot simply rely on crossbuild-essential-mips 
because building qemu requires many more system libraries than just libc.

In https://www.debian.org/releases/bullseye/, you'll note that big-endian mips is not 
listed, so we are now missing those system libraries.

We are not intending to *remove* support for big-endian mips, as 99% of the code paths are 
shared with little-endian mips, which we can continue to test.  But we are now saying that 
big-endian mips is not "supported" and might break.


r~

Le 16/09/2022 à 10:38, Richard Henderson a écrit :
> On 9/16/22 10:08, Pierre Muller wrote:
>>
>>     I am using gcc230 machine for the gcc compile farm.
>>
>>     This is a big endian mips64 machine runnig Debian Buster.
>>
>> When compiling the qemu 7.1.0 release source,
>> the generated binaries are 32-bit mips binaries,
>> and I did not find out how to generate a 64-bit versions
>> of the executables.
> 
> Yes, that host seems to have been installed with the o32 abi instead of the n64 (or n32) abi.

Indeed,
>>     As mips32 seems to still be the default arch that gcc uses,
>> I don't really understand the idea of depreciating big endian mips32.
>>
>> Is this solely related to cross-compilation issues?
> 
> Yes.  Even gcc230 is fairly small for actually compiling qemu, it takes many hours.  So
> for many hosts we rely on cross-compilation from x86_64.
> 
> For that, we rely on the set of cross-compilers built by Debian 11 (bullseye) plus (!) the
> host libraries for that platform.  We cannot simply rely on crossbuild-essential-mips
> because building qemu requires many more system libraries than just libc.
> 
> In https://www.debian.org/releases/bullseye/, you'll note that big-endian mips is not
> listed, so we are now missing those system libraries.

  So this is not limited to mips32, as big endian mips64 is also not supported anymore in bulleye...

> We are not intending to *remove* support for big-endian mips, as 99% of the code paths are
> shared with little-endian mips, which we can continue to test.  But we are now saying that
> big-endian mips is not "supported" and might break.

   Thank you for your answer and the clarifications!

Pierre

On Fri, Sep 16, 2022 at 12:10:30PM +0200, Pierre Muller wrote:
> 
> 
> Le 16/09/2022 à 10:38, Richard Henderson a écrit :
> > On 9/16/22 10:08, Pierre Muller wrote:
> > > 
> > >     I am using gcc230 machine for the gcc compile farm.
> > > 
> > >     This is a big endian mips64 machine runnig Debian Buster.
> > > 
> > > When compiling the qemu 7.1.0 release source,
> > > the generated binaries are 32-bit mips binaries,
> > > and I did not find out how to generate a 64-bit versions
> > > of the executables.
> > 
> > Yes, that host seems to have been installed with the o32 abi instead of the n64 (or n32) abi.
> 
> Indeed,
> > >     As mips32 seems to still be the default arch that gcc uses,
> > > I don't really understand the idea of depreciating big endian mips32.
> > > 
> > > Is this solely related to cross-compilation issues?
> > 
> > Yes.  Even gcc230 is fairly small for actually compiling qemu, it takes many hours.  So
> > for many hosts we rely on cross-compilation from x86_64.
> > 
> > For that, we rely on the set of cross-compilers built by Debian 11 (bullseye) plus (!) the
> > host libraries for that platform.  We cannot simply rely on crossbuild-essential-mips
> > because building qemu requires many more system libraries than just libc.
> > 
> > In https://www.debian.org/releases/bullseye/, you'll note that big-endian mips is not
> > listed, so we are now missing those system libraries.
> 
>  So this is not limited to mips32, as big endian mips64 is also not supported anymore in bulleye...

Right, so as a general policy, for a platform target to be considered
fully supported, there needs to be a non-EOL (end of life) OS distro
with which we can run automated CI. In terms of unusual architectures,
Debian has historically been our best bet for being able to put together
container images suitable for running CI.

When even Debian has dropped an architecture, as well as removing our
ability to do CI, it is also a sign of the architectures diminishing
importance to the ecosystem as a whole. This makes it hard to justify
investing in figuring out new CI options, though we're open to suggestions
and help if people can point to non-EOL platforms that can be used,
especially if container based.

We don't wish to use end of life platforms for CI, since we periodically
intend to increase our minimum required versions of 3rd party libraries,
based on what current OS ship & testing using EOL platforms would prevent
that.

FWIW: https://www.qemu.org/docs/master/about/build-platforms.html

> > We are not intending to *remove* support for big-endian mips, as 99% of the code paths are
> > shared with little-endian mips, which we can continue to test.  But we are now saying that
> > big-endian mips is not "supported" and might break.
> 
>   Thank you for your answer and the clarifications!

In practical terms the lack of CI means that we can't guarantee that a
new QEMU release will compile successfully. We're handing off responsbility
for keeping it working to any interested users to do adhoc testing of their
own. We can still accept bug reports & patches when people discover problems.

With 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 :|

On 16/9/22 12:22, Daniel P. Berrangé wrote:
> On Fri, Sep 16, 2022 at 12:10:30PM +0200, Pierre Muller wrote:
>> Le 16/09/2022 à 10:38, Richard Henderson a écrit :

>>> We are not intending to *remove* support for big-endian mips, as 99% of the code paths are
>>> shared with little-endian mips, which we can continue to test.  But we are now saying that
>>> big-endian mips is not "supported" and might break.
>>
>>    Thank you for your answer and the clarifications!
> 
> In practical terms the lack of CI means that we can't guarantee that a
> new QEMU release will compile successfully. We're handing off responsbility
> for keeping it working to any interested users to do adhoc testing of their
> own. We can still accept bug reports & patches when people discover problems.

Indeed. This is the situation of (host) HPPA. 3 people still build QEMU 
tools on it and report (build system) bugs from time to time, or send 
patches.