[PATCH v2 0/6] Deprecate support for 32-bit x86 and arm hosts
We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now. This is a follow-up patch series from the previous discussion here: https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com... where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit x86 host support and for system emulation on 32-bit arm hosts anymore, so it should be fine if we drop these host environments soon (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those). v2: - Split binary and host deprecation into separate patches - Added patches to immediately drop the jobs from the CI Thomas Huth (6): docs/about/deprecated: Deprecate the qemu-system-i386 binary docs/about/deprecated: Deprecate 32-bit x86 hosts gitlab-ci.d/crossbuilds: Drop the i386 jobs docs/about/deprecated: Deprecate the qemu-system-arm binary docs/about/deprecated: Deprecate 32-bit arm hosts gitlab-ci.d/crossbuilds: Drop the 32-bit arm system emulation jobs docs/about/deprecated.rst | 43 ++++++++++++++++++++++++++++++++++++ .gitlab-ci.d/crossbuilds.yml | 30 ------------------------- 2 files changed, 43 insertions(+), 30 deletions(-) -- 2.31.1
Hardly anybody really requires the i386 binary anymore, since the qemu-system-x86_64 binary is a proper superset. So let's deprecate the 32-bit variant now, so that we can finally stop wasting our time and CI minutes with this. With regards to 32-bit KVM support in the x86 Linux kernel, the developers confirmed that they do not need a recent qemu-system-i386 binary here: https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/ Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 15084f7bea..11700adac9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -34,6 +34,18 @@ deprecating the build option and no longer defend it in CI. The ``--enable-gcov`` build option remains for analysis test case coverage. +``qemu-system-i386`` binary (since 8.0) +''''''''''''''''''''''''''''''''''''''' + +The ``qemu-system-i386`` binary was mainly useful for running with KVM +on 32-bit x86 hosts, but most Linux distributions already removed their +support for 32-bit x86 kernels, so hardly anybody still needs this. The +``qemu-system-x86_64`` binary is a proper superset and can be used to +run 32-bit guests by selecting a 32-bit CPU model, including KVM support +on x86_64 hosts. Thus users are recommended to reconfigure their systems +to use the ``qemu-system-x86_64`` binary instead. + + System emulator command line arguments -------------------------------------- -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:01PM +0100, Thomas Huth wrote:
Hardly anybody really requires the i386 binary anymore, since the qemu-system-x86_64 binary is a proper superset. So let's deprecate the 32-bit variant now, so that we can finally stop wasting our time and CI minutes with this.
The first sentence isn't quite true wrt to KVM. Change slightly to: Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64 binary is a proper superset of the qemu-system-i386 binary. With the 32-bit host support being deprecated, it is now also possible to deprecate the qemu-system-i386 binary.
With regards to 32-bit KVM support in the x86 Linux kernel, the developers confirmed that they do not need a recent qemu-system-i386 binary here:
https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 Thu, 2023-03-02 at 18:05 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 02, 2023 at 05:31:01PM +0100, Thomas Huth wrote:
Hardly anybody really requires the i386 binary anymore, since the qemu-system-x86_64 binary is a proper superset. So let's deprecate the 32-bit variant now, so that we can finally stop wasting our time and CI minutes with this.
The first sentence isn't quite true wrt to KVM. Change slightly to:
Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64 binary is a proper superset of the qemu-system-i386 binary. With the 32-bit host support being deprecated, it is now also possible to deprecate the qemu-system-i386 binary.
+1
With regards to 32-bit KVM support in the x86 Linux kernel, the developers confirmed that they do not need a recent qemu-system-i386 binary here:
https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
With regards, Daniel
Hardly anybody still uses 32-bit x86 hosts today, so we should start deprecating them to stop wasting our time and CI minutes here. For example, there are also still some unresolved problems with these: When emulating 64-bit binaries in user mode, TCG does not honor atomicity for 64-bit accesses, which is "perhaps worse than not working at all" (quoting Richard). Let's simply make it clear that people should use 64-bit x86 hosts nowadays and we do not intend to fix/maintain the old 32-bit stuff. Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 11700adac9..a30aa8dfdf 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -208,6 +208,18 @@ 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. +32-bit x86 hosts (since 8.0) +'''''''''''''''''''''''''''' + +Support for 32-bit x86 host deployments is increasingly uncommon in +mainstream OS distributions given the widespread availability of 64-bit +x86 hardware. The QEMU project no longer considers 32-bit x86 support +to be an effective use of its limited resources, and thus intends to +discontinue it. Since all recent x86 hardware from the past >10 years +is capable of the 64-bit x86 extensions, a corresponding 64-bit OS +should be used instead. + + QEMU API (QAPI) events ---------------------- -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:02PM +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 hosts today, so we should start deprecating them to stop wasting our time and CI minutes here. For example, there are also still some unresolved problems with these: When emulating 64-bit binaries in user mode, TCG does not honor atomicity for 64-bit accesses, which is "perhaps worse than not working at all" (quoting Richard). Let's simply make it clear that people should use 64-bit x86 hosts nowadays and we do not intend to fix/maintain the old 32-bit stuff.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 11700adac9..a30aa8dfdf 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -208,6 +208,18 @@ 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.
+32-bit x86 hosts (since 8.0) +'''''''''''''''''''''''''''' + +Support for 32-bit x86 host deployments is increasingly uncommon in +mainstream OS distributions given the widespread availability of 64-bit +x86 hardware. The QEMU project no longer considers 32-bit x86 support +to be an effective use of its limited resources, and thus intends to +discontinue it. Since all recent x86 hardware from the past >10 years +is capable of the 64-bit x86 extensions, a corresponding 64-bit OS +should be used instead. + + QEMU API (QAPI) events ----------------------
-- 2.31.1
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 Thu, 2023-03-02 at 17:31 +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 hosts today, so we should start deprecating them to stop wasting our time and CI minutes here. For example, there are also still some unresolved problems with these: When emulating 64-bit binaries in user mode, TCG does not honor atomicity for 64-bit accesses, which is "perhaps worse than not working at all" (quoting Richard). Let's simply make it clear that people should use 64-bit x86 hosts nowadays and we do not intend to fix/maintain the old 32-bit stuff.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 11700adac9..a30aa8dfdf 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -208,6 +208,18 @@ 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. +32-bit x86 hosts (since 8.0) +'''''''''''''''''''''''''''' + +Support for 32-bit x86 host deployments is increasingly uncommon in +mainstream OS distributions given the widespread availability of 64- bit +x86 hardware. The QEMU project no longer considers 32-bit x86 support +to be an effective use of its limited resources, and thus intends to +discontinue it. Since all recent x86 hardware from the past >10 years +is capable of the 64-bit x86 extensions, a corresponding 64-bit OS +should be used instead. + + QEMU API (QAPI) events ----------------------
Hardly anybody still uses 32-bit x86 environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs. Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 101416080c..3ce51adf77 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -43,22 +43,6 @@ cross-arm64-user: variables: IMAGE: debian-arm64-cross -cross-i386-system: - extends: .cross_system_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check-qtest - -cross-i386-user: - extends: .cross_user_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check - cross-i386-tci: extends: .cross_accel_build_job timeout: 60m -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:03PM +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 16 ---------------- 1 file changed, 16 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> There's still the mingw 32-bit x86 build, but probably wolrth keeping that until we actually stop 32-bit from a technical POV, because Stefan still publishes the 32-bit windows installers currently Similarly the dockerfile can stay in case someone wants to reproduce a flaw locally Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 101416080c..3ce51adf77 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -43,22 +43,6 @@ cross-arm64-user: variables: IMAGE: debian-arm64-cross
-cross-i386-system: - extends: .cross_system_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check-qtest - -cross-i386-user: - extends: .cross_user_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check - cross-i386-tci: extends: .cross_accel_build_job timeout: 60m -- 2.31.1
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 Thu, 2023-03-02 at 17:31 +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 16 ---------------- 1 file changed, 16 deletions(-) Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab- ci.d/crossbuilds.yml index 101416080c..3ce51adf77 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -43,22 +43,6 @@ cross-arm64-user: variables: IMAGE: debian-arm64-cross -cross-i386-system: - extends: .cross_system_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check-qtest - -cross-i386-user: - extends: .cross_user_build_job - needs: - job: i386-fedora-cross-container - variables: - IMAGE: fedora-i386-cross - MAKE_CHECK_ARGS: check - cross-i386-tci: extends: .cross_accel_build_job timeout: 60m
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now. Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead. +``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The +latter was mainly a requirement for running KVM on 32-bit arm hosts, but +this 32-bit KVM support has been removed some years ago already (see: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... +). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a +future release. Use ``qemu-system-aarch64`` instead. + System emulator command line arguments -------------------------------------- -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:04PM +0100, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 2/3/23 17:31, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead.
+``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The +latter was mainly a requirement for running KVM on 32-bit arm hosts, but +this 32-bit KVM support has been removed some years ago already (see:
s/some/few/?
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... +). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a +future release. Use ``qemu-system-aarch64`` instead.
If we unify, wouldn't it be simpler to name the single qemu-system binary emulating various ARM architectures as 'qemu-system-arm'?
On 02/03/2023 23.16, Philippe Mathieu-Daudé wrote:
On 2/3/23 17:31, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead. +``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The +latter was mainly a requirement for running KVM on 32-bit arm hosts, but +this 32-bit KVM support has been removed some years ago already (see:
s/some/few/?
I can also use "three years ago" since the patch had been merged in March 2020.
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
+). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a +future release. Use ``qemu-system-aarch64`` instead.
If we unify, wouldn't it be simpler to name the single qemu-system binary emulating various ARM architectures as 'qemu-system-arm'?
That would be more intuitive for people who are completely new to QEMU, but I guess it will cause a lot of "you broke my script that uses the -aarch64 binary" troubles again. So I think it's likely better to not go down that road. Thomas
On Thu, 2023-03-02 at 17:31 +0100, Thomas Huth wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead. +``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The +latter was mainly a requirement for running KVM on 32-bit arm hosts, but +this 32-bit KVM support has been removed some years ago already (see: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com mit/?id=541ad0150ca4 +). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a +future release. Use ``qemu-system-aarch64`` instead. + System emulator command line arguments --------------------------------------
On Thu, 2 Mar 2023 at 16:31, Thomas Huth <thuth@redhat.com> wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead.
+``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``.
I think this is not quite true -- at the moment if you want "every feature we implement, 32-bit" the only way to get that is 'qemu-system-arm -cpu max'. The '-cpu max' on qemu-system-aarch64 is 64-bit, and we don't implement for TCG the "-cpu max,aarch64=off" syntax that we do for KVM that would let the user say "no 64-bit support". thanks -- PMM
On 03/03/2023 12.16, Peter Maydell wrote:
On Thu, 2 Mar 2023 at 16:31, Thomas Huth <thuth@redhat.com> wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead.
+``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``.
I think this is not quite true -- at the moment if you want "every feature we implement, 32-bit" the only way to get that is 'qemu-system-arm -cpu max'. The '-cpu max' on qemu-system-aarch64 is 64-bit, and we don't implement for TCG the "-cpu max,aarch64=off" syntax that we do for KVM that would let the user say "no 64-bit support".
Ok ... so what does that mean now? ... can we continue with this patch, e.g. after rephrasing the text a little bit, or do we need to implement "-cpu max,aarch64=off" for TCG first? Thomas
On Fri, Mar 03, 2023 at 12:31:42PM +0100, Thomas Huth wrote:
On 03/03/2023 12.16, Peter Maydell wrote:
On Thu, 2 Mar 2023 at 16:31, Thomas Huth <thuth@redhat.com> wrote:
qemu-system-aarch64 is a proper superset of qemu-system-arm, and the latter was mainly still required for 32-bit KVM support. But this 32-bit KVM arm support has been dropped in the Linux kernel a couple of years ago already, so we don't really need qemu-system-arm anymore, thus deprecated it now.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index a30aa8dfdf..21ce70b5c9 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, including KVM support on x86_64 hosts. Thus users are recommended to reconfigure their systems to use the ``qemu-system-x86_64`` binary instead.
+``qemu-system-arm`` binary (since 8.0) +'''''''''''''''''''''''''''''''''''''' + +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``.
I think this is not quite true -- at the moment if you want "every feature we implement, 32-bit" the only way to get that is 'qemu-system-arm -cpu max'. The '-cpu max' on qemu-system-aarch64 is 64-bit, and we don't implement for TCG the "-cpu max,aarch64=off" syntax that we do for KVM that would let the user say "no 64-bit support".
Ok ... so what does that mean now? ... can we continue with this patch, e.g. after rephrasing the text a little bit, or do we need to implement "-cpu max,aarch64=off" for TCG first?
I think we need to have a way to request the max 32-bit CPU before we deprecate, because deprecation has to tell people what they should use instead. For qemu-system-i686 -cpu max, I guess we have lm=off to hide the 64-bit support, so that's OK from QEMU POV, but will need libvirt enhancement as I don't think we've taken that into account. 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 :|
For running QEMU in system emulation mode, the user needs a rather strong host system, i.e. not only an embedded low-frequency controller. All recent beefy arm host machines should support 64-bit now, it's unlikely that anybody is still seriously using QEMU on a 32-bit arm CPU, so we deprecate the 32-bit arm hosts here to finally save use some time and precious CI minutes. Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 21ce70b5c9..c7113a7510 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -229,6 +229,15 @@ discontinue it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead. +System emulation on 32-bit arm hosts (since 8.0) +'''''''''''''''''''''''''''''''''''''''''''''''' + +Since QEMU needs a strong host machine for running full system emulation, and +all recent powerful arm hosts support 64-bit, the QEMU project deprecates the +support for running any system emulation on 32-bit arm hosts in general. Use +64-bit arm hosts for system emulation instead. (Note: "user" mode emulation +continuous to be supported on 32-bit arm hosts, too) + QEMU API (QAPI) events ---------------------- -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:05PM +0100, Thomas Huth wrote:
For running QEMU in system emulation mode, the user needs a rather strong host system, i.e. not only an embedded low-frequency controller. All recent beefy arm host machines should support 64-bit now, it's unlikely that anybody is still seriously using QEMU on a 32-bit arm CPU, so we deprecate the 32-bit arm hosts here to finally save use some time and precious CI minutes.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 9 +++++++++ 1 file changed, 9 insertions(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 21ce70b5c9..c7113a7510 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -229,6 +229,15 @@ discontinue it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead.
+System emulation on 32-bit arm hosts (since 8.0) +'''''''''''''''''''''''''''''''''''''''''''''''' + +Since QEMU needs a strong host machine for running full system emulation, and +all recent powerful arm hosts support 64-bit, the QEMU project deprecates the +support for running any system emulation on 32-bit arm hosts in general. Use +64-bit arm hosts for system emulation instead. (Note: "user" mode emulation +continuous to be supported on 32-bit arm hosts, too)
s/continuous/continues/ s/,too/, as well as command line tools like qemu-img, qemu-nbd, etc/
+
QEMU API (QAPI) events ---------------------- -- 2.31.1
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 Thu, 2023-03-02 at 17:31 +0100, Thomas Huth wrote:
For running QEMU in system emulation mode, the user needs a rather strong host system, i.e. not only an embedded low-frequency controller. All recent beefy arm host machines should support 64-bit now, it's unlikely that anybody is still seriously using QEMU on a 32-bit arm CPU, so we deprecate the 32-bit arm hosts here to finally save use some time and precious CI minutes.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 9 +++++++++ 1 file changed, 9 insertions(+) Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 21ce70b5c9..c7113a7510 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -229,6 +229,15 @@ discontinue it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead. +System emulation on 32-bit arm hosts (since 8.0) +'''''''''''''''''''''''''''''''''''''''''''''''' + +Since QEMU needs a strong host machine for running full system emulation, and +all recent powerful arm hosts support 64-bit, the QEMU project deprecates the +support for running any system emulation on 32-bit arm hosts in general. Use +64-bit arm hosts for system emulation instead. (Note: "user" mode emulation +continuous to be supported on 32-bit arm hosts, too) + QEMU API (QAPI) events ----------------------
Hardly anybody still uses 32-bit arm environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs. Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index 3ce51adf77..419b0c2fe1 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -1,13 +1,6 @@ include: - local: '/.gitlab-ci.d/crossbuild-template.yml' -cross-armel-system: - extends: .cross_system_build_job - needs: - job: armel-debian-cross-container - variables: - IMAGE: debian-armel-cross - cross-armel-user: extends: .cross_user_build_job needs: @@ -15,13 +8,6 @@ cross-armel-user: variables: IMAGE: debian-armel-cross -cross-armhf-system: - extends: .cross_system_build_job - needs: - job: armhf-debian-cross-container - variables: - IMAGE: debian-armhf-cross - cross-armhf-user: extends: .cross_user_build_job needs: -- 2.31.1
On Thu, Mar 02, 2023 at 05:31:06PM +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit arm environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 14 -------------- 1 file changed, 14 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> 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 2/3/23 17:31, Thomas Huth wrote:
Hardly anybody still uses 32-bit arm environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 14 -------------- 1 file changed, 14 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
On Thu, 2023-03-02 at 17:31 +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit arm environments for running QEMU, so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- .gitlab-ci.d/crossbuilds.yml | 14 -------------- 1 file changed, 14 deletions(-) Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab- ci.d/crossbuilds.yml index 3ce51adf77..419b0c2fe1 100644 --- a/.gitlab-ci.d/crossbuilds.yml +++ b/.gitlab-ci.d/crossbuilds.yml @@ -1,13 +1,6 @@ include: - local: '/.gitlab-ci.d/crossbuild-template.yml' -cross-armel-system: - extends: .cross_system_build_job - needs: - job: armel-debian-cross-container - variables: - IMAGE: debian-armel-cross - cross-armel-user: extends: .cross_user_build_job needs: @@ -15,13 +8,6 @@ cross-armel-user: variables: IMAGE: debian-armel-cross -cross-armhf-system: - extends: .cross_system_build_job - needs: - job: armhf-debian-cross-container - variables: - IMAGE: debian-armhf-cross - cross-armhf-user: extends: .cross_user_build_job needs:
On 2/3/23 17:31, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now.
This is a follow-up patch series from the previous discussion here:
https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com...
where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit x86 host support and for system emulation on 32-bit arm hosts anymore, so it should be fine if we drop these host environments soon (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those).
It is not clear from your cover that the deprecation only concern system emulation on these hosts, not user emulation. I wonder about tools. Apparently they depend on sysemu now. I was building a 'configure --enable-tools --disable-system' but now it is empty.
On 02/03/2023 23.07, Philippe Mathieu-Daudé wrote:
On 2/3/23 17:31, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared gitlab runners, so we urgently need to think of ways to cut down our supported build and target environments. qemu-system-i386 and qemu-system-arm are not really required anymore, since nobody uses KVM on the corresponding systems for production anymore, and the -x86_64 and -arch64 variants are a proper superset of those binaries. So it's time to deprecate them and the corresponding 32-bit host environments now.
This is a follow-up patch series from the previous discussion here:
https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-thuth@redhat.com...
where people still mentioned that there is still interest in certain support for 32-bit host hardware. But as far as I could see, there is no real need for 32-bit x86 host support and for system emulation on 32-bit arm hosts anymore, so it should be fine if we drop these host environments soon (these are also the two architectures that contribute the most to the long test times in our CI, so we would benefit a lot by dropping those).
It is not clear from your cover that the deprecation only concern system emulation on these hosts, not user emulation.
x86 ==> deprecate both, user and system emulation support on 32-bit hosts arm ==> deprecate only system emulation on 32-bit hosts. I tried to say it with the sentence "there is no real need for 32-bit x86 host support and for system emulation on 32-bit arm hosts anymore, so it should be fine if we drop these host environments soon" ... not sure why it's unclear, but if you have some better sentences, I'm open for suggestions.
I wonder about tools. Apparently they depend on sysemu now. I was building a 'configure --enable-tools --disable-system' but now it is empty.
I just did a try in a fresh build directory, and for me it was working: it builds qemu-img, qemu-io, qemu-edid etc. just fine. What was missing in your case? Thomas
Hello! On Fri, 2023-03-03 at 10:48 +0100, Thomas Huth wrote:
x86 ==> deprecate both, user and system emulation support on 32-bit hosts arm ==> deprecate only system emulation on 32-bit hosts.
I would recommend against dropping support for 32-bit hosts for qemu-user as there are some cases where the emulation of 32-bit user code on 64-bit hosts does not work properly [1]. Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 03/03/2023 12.09, John Paul Adrian Glaubitz wrote:
Hello!
On Fri, 2023-03-03 at 10:48 +0100, Thomas Huth wrote:
x86 ==> deprecate both, user and system emulation support on 32-bit hosts arm ==> deprecate only system emulation on 32-bit hosts.
I would recommend against dropping support for 32-bit hosts for qemu-user as there are some cases where the emulation of 32-bit user code on 64-bit hosts does not work properly [1].
Adrian
The ticket is very long and hard to read, but ... oh my, does that mean you need to compile qemu-user in 32-bit mode on a 64-bit x86 host to properly run 32-bit binaries from other architectures? ... uh, that's ugly ... and sounds like bug in QEMU's user mode emulation ... and what if you're running a distro (or different 64-bit host architecutre) that does not support 32-bit userspace libraries anymore? Then you're lost? Thomas
Hi Thomas! On Fri, 2023-03-03 at 12:22 +0100, Thomas Huth wrote:
The ticket is very long and hard to read, but ... oh my, does that mean you need to compile qemu-user in 32-bit mode on a 64-bit x86 host to properly run 32-bit binaries from other architectures? ... uh, that's ugly ... and sounds like bug in QEMU's user mode emulation ... and what if you're running a distro (or different 64-bit host architecutre) that does not support 32-bit userspace libraries anymore? Then you're lost?
Perhaps the explanation here by Florian Weimer is a bit easier to understand:
https://lore.kernel.org/lkml/87bm56vqg4.fsf@mid.deneb.enyo.de/
Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, 3 Mar 2023 at 11:09, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
Hello!
On Fri, 2023-03-03 at 10:48 +0100, Thomas Huth wrote:
x86 ==> deprecate both, user and system emulation support on 32-bit hosts arm ==> deprecate only system emulation on 32-bit hosts.
I would recommend against dropping support for 32-bit hosts for qemu-user as there are some cases where the emulation of 32-bit user code on 64-bit hosts does not work properly [1].
Adrian
I failed entirely to get any traction with persuading the kernel folks to provide an API to let QEMU work in that "32-bit guest wants a 32-bit dirent but the kernel is providing a 64-bit hash value as a dirent" case. Somebody kindly wrote some kernel patches but they went absolutely nowhere. It seems to only happen for certain kinds of 32-bit guest, where the guest libc is not also using 64-bit dirents. So at least as far as Arm guests are concerned the effective result was "the older arm binaries that were built to need a 32-bit dirent are just not around any more, so very few people run into the problem". You can also work around it by using a different host filesystem type, I think. thanks -- PMM
participants (6)
-
Daniel P. Berrangé -
John Paul Adrian Glaubitz -
Peter Maydell -
Philippe Mathieu-Daudé -
Thomas Huth -
Wilfred Mallawa