[PATCH] docs: Fix some types
From: Thomas Huth Found with the codespell utility. Signed-off-by: Thomas Huth --- docs/formatcaps.rst| 2 +- docs/formatdomain.rst | 4 ++-- docs/glib-adoption.rst | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index da6b215780..7e525487e7 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -39,7 +39,7 @@ The element consists of the following child elements: The host CPU architecture and features. Note that, while this element contains a ``topology`` sub-element, - the information contained therein is farily high-level and likely + the information contained therein is fairly high-level and likely not very useful when it comes to optimizing guest vCPU placement. Look into the ``topology`` *element*, described below, for more detailed information. diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c1876ad467..4bc6a318f5 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3468,7 +3468,7 @@ paravirtualized driver is specified via the ``disk`` element. automatically distributed among the configured iothreads. Optionally the ``iothread`` element can have multiple ``queue`` - subelements with mandatory ``id`` atribute specifying that the iothread + subelements with mandatory ``id`` attribute specifying that the iothread should be used to handle given virt queue. If queue mapping is present the ``queues`` attribute of ``driver`` must be configured and all configured virt queues must be included in the mapping. The @@ -8423,7 +8423,7 @@ Example: usage of external TPM emulator :since:`Since 9.0.0` This element does not work with the ``passthrough`` backend. - When specified, it is the user's responsability to prevent files from being + When specified, it is the user's responsibility to prevent files from being used by multiple VMs or emulators (swtpm will also use advisory locking). If not specified, the storage configuration is left to libvirt discretion. diff --git a/docs/glib-adoption.rst b/docs/glib-adoption.rst index f969ac80a1..c2cec80eea 100644 --- a/docs/glib-adoption.rst +++ b/docs/glib-adoption.rst @@ -32,7 +32,7 @@ Array operations https://developer.gnome.org/glib/stable/glib-Arrays.html - Instead of using plain C arrays, it is preferrable to use one of + Instead of using plain C arrays, it is preferable to use one of the GLib types, ``GArray``, ``GPtrArray`` or ``GByteArray``. These all use a struct to track the array memory and size together and efficiently resize. -- 2.48.1
Re: [PATCH] docs: Fix some types
On 17/03/2025 12.29, Martin Kletzander wrote: On Mon, Mar 17, 2025 at 11:41:20AM +0100, Thomas Huth via Devel wrote: From: Thomas Huth Found with the codespell utility. If you did that typo in the subject on purpose, then hat's off to you. Anyway, before pushing it, s/types/typos/ please LOL, that was not on purpose, thanks for catching it! Thomas
Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common
On 29/04/2025 21.48, Pierrick Bouvier wrote: ... I'm not keen to have a default target set, but it's a personal opinion based on fear of "implicit smart choice hurts", so I'll be happy to change my mind with a good argument for it. No default target, please! We've seen this with the default machines - it looks convenient first, but only gives troubles in the long run. Preferred defaults can change in the course of time, but if you have baked in the logic in hundreds of scripts out there, it's hard to change it afterwards again. Thomas
Re: [PATCH v2 4/5] docs/about/removed-features: auto-generate a note for versioned machine types
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
We remove versioned machine types on a fixed schedule. This allows us
to auto-generate a paragraph in the removed-features.rst document that
always has accurate version info.
Signed-off-by: Daniel P. Berrangé
---
docs/about/removed-features.rst | 10 ++
docs/conf.py| 2 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 790a5e481c..59fec3c9a1 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -981,10 +981,12 @@ from Linux in 2021, and is not supported anymore by QEMU
either.
System emulator machines
-Note: Versioned machine types that have been introduced in a QEMU version
-that has initially been released more than 6 years before are considered
-obsolete and will be removed without further notice in this document.
-Please use newer machine types instead.
+Versioned machine types (aarch64, arm, i386, m68k, ppc, ppc64, s390x, x86_64)
I think we don't have versioned machine types for 32-bit ppc, do we?
(pseries is 64-bit only)
Thomas
+'
+
+In accordance with our versioned machine type deprecation policy, all machine
+types with version |VER_MACHINE_DELETION_VERSION|, or older, have been
+removed.
``s390-virtio`` (removed in 2.6)
diff --git a/docs/conf.py b/docs/conf.py
index 60dcf2a541..248ff8cf5d 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -137,6 +137,7 @@
minor += 1
ver_machine_deprecation_version = "%d.%d.0" % (major - 3, minor)
+ver_machine_deletion_version = "%d.%d.0" % (major - 6, minor)
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
@@ -170,6 +171,7 @@
vars = {
"CONFDIR": confdir,
"VER_MACHINE_DEPRECATION_VERSION": ver_machine_deprecation_version,
+"VER_MACHINE_DELETION_VERSION": ver_machine_deletion_version,
}
rst_epilog = "".join([
Re: [PATCH v3 0/5] docs: automated info about machine deprecation/removal info
On 06/05/2025 18.00, Daniel P. Berrangé wrote: Since we deprecate and remove versioned machine types on a fixed schedule, we can automatically ensure that the docs reflect the latest version info, rather than requiring manual updates on each dev cycle. The first patch in this series removes the hack which postponed automatic removal of versioned machine types to the 10.1.0 release, since we're now in the 10.1.0 dev cycle. The second patch in this series fixes the logic to ensure dev snapshots and release candidates don't have an off-by-1 error in setting deprecation and removal thresholds - they must predict the next formal release version number. The following three patches deal with the docs stuff. Series Reviewed-by: Thomas Huth
Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common
On 29/04/2025 10.23, Markus Armbruster wrote: ... I don't wish to derail this thread, but we've been dancing around the question of how to best fix the target for some time. I think we should talk about it for real. Mind, this is not an objection to your larger "single binary" idea. It could be only if it was an intractable problem, but I don't think it is. You want the single binary you're trying to create to be a drop-in replacement for per-target binaries. "Drop-in replacement" means existing usage continues to work. Additional interfaces are not a problem. To achieve "drop-in replacement", the target needs to be fixed automatically, and before the management application can further interact with it. If I understand you correctly, you're proposing to use argv[0] for that, roughly like this: assume it's qemu-system-, extract first thing in main(), done. What if it's not named that way? If I understand you correctly, you're proposing to fall back to a compiled-in default target. I don't think this is going to fly. I tend to disagree. For normal users that consume QEMU via the distros, the check via argv[0] should be good enough. For developers, I think we can assume that they are adaptive enough to use an additional "-target" option in case they mis-named their binary in a bad way. Developers rename the binary all the time, and expect this not to change behavior. For instance, I routinely rename qemu-FOO to qemu-FOO.old or qemu-FOO.COMMIT-HASH to let me compare behavior easily. Developers should already be aware that this can cause trouble, since e.g. the qtests are deriving the target architecture from the binary name already. See the qtest_get_arch() function. We could relax the assumption to support such renames. Developers then need to be aware of what renames are supported. Meh. The more we relax the pattern, the likelier surprising behavior becomes. We could mitigate surprises by eliminating the built-in default target. Just print out a proper error message if the target cannot be derived from argv[0], pointing the users to use "-target", and we should be fine. And if someone renames their "qemu-sytem-aarch64" symlink to "qemu-system-x86_64" and still expect to run aarch64 images that way, that's just plain stupidity. Users invoke their binaries with their own names, too. If Joe R. User finds qemu-system- too much to type, and creates a symlink named q to it, more power to him! They can also either use shell aliases or short shell scripts to achieve that goal, so that's not really a show stopper. Distributions have packaged renamed binaries. qemu-kvm has been used quite widely. Yes, and QEMU already checks for that naming in configure_accelerators() ... so that's rather another indicator that we can go with configuration via argv[0] :-) In neither of these cases, relaxing the pattern helps. The least bad solution I can see so far is a new option -target. Instead of turning the target-specific binaries into links to / copies of the single binary, they become wrappers that pass -target as the first option. We need to make sure this option is honored in time then, which should be easy enough. If you invoke the single binary directly, you need to pass -target yourself. If you don't to pass it, or pass it late in the command line, you open up a window for interaction with indeterminate target. Target-specific interfaces could exhibit different behavior then, even fail. That's fine under "additional interfaces are not a problem". Thoughts? Shell script wrappers always have the problem that they break the direct usage of debuggers like "valgrind" or "gdb" with the target binary, so that's also not the best solution. I'd go with Pierrick's idea to try to determine the target via argv[0]. And for people who really want to rename their binary in a way that makes it impossible to determine the target automatically, just provide the "-target" option as fallback solution, too. Thomas
Re: [PATCH v2 3/5] docs/about/deprecated: auto-generate a note for versioned machine types
On 29/04/2025 15.15, Daniel P. Berrangé wrote: We deprecate versioned machine types on a fixed schedule. This allows us to auto-generate a paragraph in the deprecated.rst document that always has accurate version info. Signed-off-by: Daniel P. Berrangé --- docs/about/deprecated.rst | 7 +++ docs/conf.py | 33 - 2 files changed, 39 insertions(+), 1 deletion(-) Reviewed-by: Thomas Huth
Re: [PATCH v2 2/5] include/hw/boards: cope with dev/rc versions in deprecation checks
On 29/04/2025 15.15, Daniel P. Berrangé wrote: When VERSION is set to a development snapshot (micro >= 50), or a release candidate (micro >= 90) we have an off-by-1 in determining deprecation and deletion thresholds for versioned machine types. In such cases we need to use the next major/minor version in threshold checks. This adapts the deprecation macros to do "next version" prediction when seeing a dev/rc version number. This ensures users of release candidates get an accurate view of machines that will be deprecated/deleted in the final release. This requires hardcoding our current release policy of 3 releases per year, with a major bump at the start of each year, and that dev/rc versions have micro >= 50. Signed-off-by: Daniel P. Berrangé --- include/hw/boards.h | 33 - 1 file changed, 32 insertions(+), 1 deletion(-) Reviewed-by: Thomas Huth
Re: [PATCH v2 1/5] Revert "include/hw: temporarily disable deletion of versioned machine types"
On 29/04/2025 15.15, Daniel P. Berrangé wrote:
This reverts commit c9fd2d9a48ee3c195cf83cc611b87b09f02f0013.
When we introduced the specialized machine type deprecation policy, we
allow automatic deprecation to take effect immediately, but blocked the
automatic deletion of machine types for 2 releases. This ensured we
complied with the historical deprecation policy during the transition
window. Startnig with the 10.1.0 dev cycle, the old machine types would
typo: Startnig
be candidates for removal under both the old and new deprecation
policies.
Thus we can now enable automatic deletion of old machine types, which
takes effect by skipping the QOM type registration. This prevents the
machine types being listed with '-machine help', and blocks their
creation. The actual code can be purged at a convenient time of the
maintainer's choosing.
In the case of the x86_64 target, this change results in the blocking
of the following machine types:
pc-i440fx-4.0Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-3.1Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-3.0Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.9Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.8Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.7Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.6Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.5Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.4Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.12 Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.11 Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-2.10 Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-q35-4.0.1 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-4.0 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-3.1 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-3.0 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.9 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.8 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.7 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.6 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.5 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.4 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.12 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.11 Standard PC (Q35 + ICH9, 2009) (deprecated)
pc-q35-2.10 Standard PC (Q35 + ICH9, 2009) (deprecated)
Signed-off-by: Daniel P. Berrangé
---
include/hw/boards.h | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 765dc8dd35..74a8e96b2e 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -719,28 +719,11 @@ struct MachineState {
* suitable period of time has passed, it will cause
* execution of the method to return, avoiding registration
* of the machine
- *
- * The new deprecation and deletion policy for versioned
- * machine types was introduced in QEMU 9.1.0.
- *
- * Under the new policy a number of old machine types (any
- * prior to 2.12) would be liable for immediate deletion
- * which would be a violation of our historical deprecation
- * and removal policy
- *
- * Thus deletions are temporarily gated on existance of
- * the env variable "QEMU_DELETE_MACHINES" / QEMU version
- * number >= 10.1.0. This gate can be deleted in the 10.1.0
- * dev cycle
*/
#define MACHINE_VER_DELETION(...) \
do { \
if (MACHINE_VER_SHOULD_DELETE(__VA_ARGS__)) { \
-if (getenv("QEMU_DELETE_MACHINES") || \
-QEMU_VERSION_MAJOR > 10 || (QEMU_VERSION_MAJOR == 10 && \
-QEMU_VERSION_MINOR >= 1)) { \
-return; \
-} \
+return; \
I wonder whether we might want to have it the other way round now instead,
so that we could re-activate the dead machines in case a certain environment
variable (QEMU_ZOMBI_MACHINES) is set? Anyway, just an idea, not sure
whether it's a good one. So for this patch:
Reviewed-by: Thomas Huth
} \
} while (0)
Re: [PATCH v3 2/5] include/hw/boards: cope with dev/rc versions in deprecation checks
On 06/05/2025 18.00, Daniel P. Berrangé wrote: When VERSION is set to a development snapshot (micro >= 50), or a release candidate (micro >= 90) we have an off-by-1 in determining deprecation and deletion thresholds for versioned machine types. In such cases we need to use the next major/minor version in threshold checks. This adapts the deprecation macros to do "next version" prediction when seeing a dev/rc version number. This ensures users of release candidates get an accurate view of machines that will be deprecated/deleted in the final release. This requires hardcoding our current release policy of 3 releases per year, with a major bump at the start of each year, and that dev/rc versions have micro >= 50. Signed-off-by: Daniel P. Berrangé --- include/hw/boards.h | 33 - 1 file changed, 32 insertions(+), 1 deletion(-) FYI, this causes a failure in the CI now: https://gitlab.com/thuth/qemu/-/jobs/9965651507#L163 Looks like we have to remove the related subtest now? Thomas
Re: [RFC PATCH 6/6] docs/about: deprecate add sparc/sparc32plus-*-user
On 16/07/2025 12.54, Alex Bennée wrote: Even with a toolchain *-user is still broken. Maybe we should just deprecate the target. I haven't deprecated for system as we have functional tests that work and will continue to do so. Signed-off-by: Alex Bennée --- docs/about/deprecated.rst | 8 1 file changed, 8 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index d50645a071..c2199129d8 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -267,6 +267,14 @@ known-good implementation to test against. GCC is in the process of dropping their support for iwMMXt codegen. These CPU types are therefore deprecated in QEMU, and will be removed in a future release. +``sparc`` and ``sparc32plus`` (since 10.1) +'' + +Without regular testing these targets have bit-rotted and even after +scrapping together the seemingly last packaged toolchain we can't +generate binaries that can currently be run. I think it's fair to deprecate it in this case. If someone wants to maintain it, they can come up with patches and we can revert this patch. Otherwise it's only dead code anyway. Reviewed-by: Thomas Huth
Re: [PATCH v5 0/5] Disable Deprecated Features by Default on s390 CPU Models
On 30/06/2025 05.19, Collin Walling wrote: Changelog v5 - dropped the "none" test in qemuxmlactivetest (see commit for details) - reordered patches to introduce some tests first, then add qemu.conf changes v4 - added qemu.conf option to dictate the default behavior for the deprecated_features attribute (Boris) - added qemuxmlactivetests (Boris) - snuck in missing documentation for deprecated_features in formatdomain.rst v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU *host models* migration ready from the get-go by introducing a qemu.conf option for disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. The configured behavior may be overridden by explicitly providing the attribute within the guest XML. The patch series sounds reasonable to me, so FWIW: Series Acked-by: Thomas Huth Peter, Michal, could we still get this merged for libvirt 11.6 ? Thomas
Re: [PATCH 21/31] qemu: Drop skip for USB controllers on s390x
On 19/08/2025 18.22, Andrea Bolognani via Devel wrote: We have just changed PostParse so that MODEL_USB_NONE will be used instead of MODEL_USB_DEFAULT, so this code is no longer doing anything. Signed-off-by: Andrea Bolognani --- src/qemu/qemu_command.c | 5 - 1 file changed, 5 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index f5a80f6955..aabc3d773f 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3086,11 +3086,6 @@ qemuBuildControllersByTypeCommandLine(virCommand *cmd, /* skip USB controllers with type none*/ if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE) continue; - -/* skip 'default' controllers on s390 for legacy reasons */ -if (ARCH_IS_S390(def->os.arch) && -cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_DEFAULT) -continue; } if (qemuBuildControllerDevProps(def, cont, qemuCaps, &props) < 0) Reviewed-by: Thomas Huth
Re: [PATCH 20/31] qemu: Always default to no USB controller on s390x
On 19/08/2025 18.22, Andrea Bolognani via Devel wrote: When support for s390x was introduced in libvirt, it naturally followed the conventions established at the time for x86, which were to have a USB controller added by default. Later, in 2013, commit 3a82f628a964 made the default USB controller model for s390x VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE, effectively overriding the architecture-independent default. However, an exception was carved out at the time: if the USB controller had an address assigned to it, then it would be left alone. A couple of years later, commit 09ab9dcc85ec changed things again in two ways: for starters, libvirt would no longer automatically attempt to add a USB controller to newly-defined s390x guests; moreover, the command line generator was changed so that the legacy USB controller (-usb) would never be used on s390x. In other words, unless a model name is explicitly provided for the USB controller, which is something that only actually works when using a recent QEMU version (see commit f9ed4d385ab8), s390x guests will never have USB controllers attached to them. Remove the exception carved out a decade ago and always reflect this fact accurately in the guest XML. Signed-off-by: Andrea Bolognani --- src/qemu/qemu_postparse.c | 15 ++- .../qemuhotplug-base-ccw-live+ccw-virtio.xml | 5 + ...ive-with-2-ccw-virtio+ccw-virtio-1-reverse.xml | 5 + ...emuhotplug-base-ccw-live-with-2-ccw-virtio.xml | 5 + ...live-with-ccw-virtio+ccw-virtio-2-explicit.xml | 5 + ...base-ccw-live-with-ccw-virtio+ccw-virtio-2.xml | 5 + .../qemuhotplug-base-ccw-live-with-ccw-virtio.xml | 5 + .../qemuhotplug-base-ccw-live.xml | 5 + .../s390-usb-address.s390x-latest.xml | 6 +- 9 files changed, 18 insertions(+), 38 deletions(-) Reviewed-by: Thomas Huth
Re: [PATCH v2 18/27] tests/lcitool: enable rust & refresh
On 24/09/2025 14.04, marcandre.lur...@redhat.com wrote: From: Marc-André Lureau Enable Rust on various distro images: alpine, centos, debian, fedora, opensuse. Signed-off-by: Marc-André Lureau --- tests/docker/dockerfiles/alpine.docker | 2 ++ tests/docker/dockerfiles/centos9.docker| 2 ++ 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 ++ .../dockerfiles/debian-mips64el-cross.docker | 2 ++ .../docker/dockerfiles/debian-mipsel-cross.docker | 2 ++ .../docker/dockerfiles/debian-ppc64el-cross.docker | 2 ++ .../docker/dockerfiles/debian-riscv64-cross.docker | 2 ++ tests/docker/dockerfiles/debian-s390x-cross.docker | 2 ++ tests/docker/dockerfiles/debian.docker | 2 ++ .../docker/dockerfiles/fedora-rust-nightly.docker | 2 ++ tests/docker/dockerfiles/fedora.docker | 2 ++ tests/docker/dockerfiles/opensuse-leap.docker | 2 ++ tests/lcitool/refresh | 14 +++--- 16 files changed, 41 insertions(+), 3 deletions(-) Reviewed-by: Thomas Huth
Re: [PATCH v2 6/7] kvm/mips: Remove support for 32-bit hosts
On 09/10/2025 21.52, Philippe Mathieu-Daudé wrote: See previous commit for rationale. Signed-off-by: Philippe Mathieu-Daudé --- meson.build | 2 -- 1 file changed, 2 deletions(-) diff --git a/meson.build b/meson.build index afaefa01722..c5710a6a47c 100644 --- a/meson.build +++ b/meson.build @@ -295,8 +295,6 @@ elif cpu == 'ppc' kvm_targets = ['ppc-softmmu'] elif cpu == 'ppc64' kvm_targets = ['ppc-softmmu', 'ppc64-softmmu'] -elif cpu == 'mips' - kvm_targets = ['mips-softmmu', 'mipsel-softmmu'] elif cpu == 'mips64' kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu'] elif cpu == 'riscv32' Reviewed-by: Thomas Huth
Re: [PATCH v2 7/7] buildsys: Remove support for 32-bit MIPS hosts
On 09/10/2025 21.52, Philippe Mathieu-Daudé wrote:
Stop detecting 32-bit MIPS host as supported, update the
deprecation document. See previous commit for rationale.
Signed-off-by: Philippe Mathieu-Daudé
---
docs/about/deprecated.rst | 13 +
docs/about/removed-features.rst | 6 ++
configure | 7 ---
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 67e527740c0..79cc34cfeb6 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -172,17 +172,14 @@ This argument has always been ignored.
Host Architectures
--
-Big endian MIPS since 7.2; 32-bit little endian MIPS since 9.2, MIPS since 11.0
-'''
+MIPS (since 11.0)
+'
-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
+MIPS is not supported by Debian 13 ("Trixie") and newer, 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.
-Likewise, MIPS is not supported by Debian 13 ("Trixie") and newer.
-
System emulation on 32-bit x86 hosts (since 8.0)
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index a5338e44c24..53829f59e65 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -896,6 +896,12 @@ work around the atomicity issues in system mode by running
all vCPUs
in a single thread context; in user mode atomicity was simply broken.
From 10.0, QEMU has disabled configuration of 64-bit guests on 32-bit hosts.
+32-bit MIPS (since 11.0)
+
+
+Debian 12 "Bookworm" removed support for 32-bit MIPS, making it hard to
+maintain our cross-compilation CI tests of the architecture.
+
Guest Emulator ISAs
---
diff --git a/configure b/configure
index 6a633ac2b16..8236f43e8f9 100755
--- a/configure
+++ b/configure
@@ -404,8 +404,6 @@ elif check_define _ARCH_PPC ; then
elif check_define __mips__ ; then
if check_define __mips64 ; then
cpu="mips64"
- else
-cpu="mips"
fi
elif check_define __s390__ ; then
if check_define __s390x__ ; then
@@ -473,11 +471,6 @@ case "$cpu" in
host_arch=mips
linux_arch=mips
;;
- mips*)
-cpu=mips
-host_arch=mips
-linux_arch=mips
-;;
ppc)
host_arch=ppc
Reviewed-by: Thomas Huth
