From: Thomas Huth <thuth@redhat.com>

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. And with
the 32-bit x86 host support being removed now, it is possible to
deprecate the qemu-system-i386 binary now, too.

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/

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 docs/about/deprecated.rst | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index a6d6a713265..2de51337d75 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
 command line (``-M spike``).
 
 
+System emulator binaries
+------------------------
+
+``qemu-system-i386`` binary (since 11.1)
+''''''''''''''''''''''''''''''''''''''''
+
+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. If a 32-bit CPU guest
+environment should be enforced, you can switch off the "long mode" CPU
+flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
+to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
+disabled.
+
+
 Backend options
 ---------------
 
-- 
2.53.0

On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> From: Thomas Huth <thuth@redhat.com>
> 
> 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. And with
> the 32-bit x86 host support being removed now, it is possible to
> deprecate the qemu-system-i386 binary now, too.
> 
> 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/
> 
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  docs/about/deprecated.rst | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index a6d6a713265..2de51337d75 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
>  command line (``-M spike``).
>  
>  
> +System emulator binaries
> +------------------------
> +
> +``qemu-system-i386`` binary (since 11.1)
> +''''''''''''''''''''''''''''''''''''''''
> +
> +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. If a 32-bit CPU guest
> +environment should be enforced, you can switch off the "long mode" CPU
> +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> +disabled.

Why don't we just have our install rules create the symlink from
qemu-system-x86_64 to qemu-system-i386. That gives us near zero
ongoing maint cost, without need to deprecate stuff / impact users


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> 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. And with
>> the 32-bit x86 host support being removed now, it is possible to
>> deprecate the qemu-system-i386 binary now, too.
>>
>> 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/
>>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   docs/about/deprecated.rst | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index a6d6a713265..2de51337d75 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
>>   command line (``-M spike``).
>>   
>>   
>> +System emulator binaries
>> +------------------------
>> +
>> +``qemu-system-i386`` binary (since 11.1)
>> +''''''''''''''''''''''''''''''''''''''''
>> +
>> +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. If a 32-bit CPU guest
>> +environment should be enforced, you can switch off the "long mode" CPU
>> +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
>> +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
>> +disabled.
> 
> Why don't we just have our install rules create the symlink from
> qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> ongoing maint cost, without need to deprecate stuff / impact users

I think we should do that once the deprecation period is over and we don't 
allow to build QEMU in this mode anymore. I would rather not jump directly 
to that state to provide people some time for experimenting whether this new 
approach works as expected in all scenarios that are in use.

  Thomas

On Thu, Apr 02, 2026 at 12:11:37PM +0200, Thomas Huth wrote:
> On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> > On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> > > From: Thomas Huth <thuth@redhat.com>
> > > 
> > > 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. And with
> > > the 32-bit x86 host support being removed now, it is possible to
> > > deprecate the qemu-system-i386 binary now, too.
> > > 
> > > 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/
> > > 
> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > ---
> > >   docs/about/deprecated.rst | 19 +++++++++++++++++++
> > >   1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > > index a6d6a713265..2de51337d75 100644
> > > --- a/docs/about/deprecated.rst
> > > +++ b/docs/about/deprecated.rst
> > > @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
> > >   command line (``-M spike``).
> > > +System emulator binaries
> > > +------------------------
> > > +
> > > +``qemu-system-i386`` binary (since 11.1)
> > > +''''''''''''''''''''''''''''''''''''''''
> > > +
> > > +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. If a 32-bit CPU guest
> > > +environment should be enforced, you can switch off the "long mode" CPU
> > > +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> > > +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> > > +disabled.
> > 
> > Why don't we just have our install rules create the symlink from
> > qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> > ongoing maint cost, without need to deprecate stuff / impact users
> 
> I think we should do that once the deprecation period is over and we don't
> allow to build QEMU in this mode anymore. I would rather not jump directly
> to that state to provide people some time for experimenting whether this new
> approach works as expected in all scenarios that are in use.

This feels a bit wierd as a deprecation though.  We're telling people
not to use  qemu-system-i386 and yet we intend to continue providing
it via a symlink and expect full back compatibility and people can
carry on with it forever.


I think this is probably something better handled via a build time
option & messages from

  * Step 1: full i686 binary by default but have --enable-i686-compat
            to switch to symlink. Issue hint message that symlink will
	    become the default in future & asking for feedback if
	    --enable-i686-compat is not given

  * Step 2: symlink i686 binary by default but have --disable-i686-compat
            to switch to full binary. Issue *WARNING* that full binary
	    will be soon removed if --disable-i686-compat is given

  * Step 3: remove full binary

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

On Thu, Apr 02, 2026 at 11:41:02AM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 02, 2026 at 12:11:37PM +0200, Thomas Huth wrote:
> > On 02/04/2026 12.06, Daniel P. Berrangé wrote:
> > > On Thu, Apr 02, 2026 at 11:51:32AM +0200, Thomas Huth wrote:
> > > > From: Thomas Huth <thuth@redhat.com>
> > > > 
> > > > 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. And with
> > > > the 32-bit x86 host support being removed now, it is possible to
> > > > deprecate the qemu-system-i386 binary now, too.
> > > > 
> > > > 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/
> > > > 
> > > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > ---
> > > >   docs/about/deprecated.rst | 19 +++++++++++++++++++
> > > >   1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > > > index a6d6a713265..2de51337d75 100644
> > > > --- a/docs/about/deprecated.rst
> > > > +++ b/docs/about/deprecated.rst
> > > > @@ -301,6 +301,25 @@ machine must ensure that they're setting the ``spike`` machine in the
> > > >   command line (``-M spike``).
> > > > +System emulator binaries
> > > > +------------------------
> > > > +
> > > > +``qemu-system-i386`` binary (since 11.1)
> > > > +''''''''''''''''''''''''''''''''''''''''
> > > > +
> > > > +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. If a 32-bit CPU guest
> > > > +environment should be enforced, you can switch off the "long mode" CPU
> > > > +flag with ``-cpu max,lm=off``, or rename/symlink ``qemu-system-x86_64``
> > > > +to ``qemu-system-i386`` -- QEMU will then run with the 64-bit extensions
> > > > +disabled.
> > > 
> > > Why don't we just have our install rules create the symlink from
> > > qemu-system-x86_64 to qemu-system-i386. That gives us near zero
> > > ongoing maint cost, without need to deprecate stuff / impact users
> > 
> > I think we should do that once the deprecation period is over and we don't
> > allow to build QEMU in this mode anymore. I would rather not jump directly
> > to that state to provide people some time for experimenting whether this new
> > approach works as expected in all scenarios that are in use.
> 
> This feels a bit wierd as a deprecation though.  We're telling people
> not to use  qemu-system-i386 and yet we intend to continue providing
> it via a symlink and expect full back compatibility and people can
> carry on with it forever.
> 
> 
> I think this is probably something better handled via a build time
> option & messages from
> 
>   * Step 1: full i686 binary by default but have --enable-i686-compat
>             to switch to symlink. Issue hint message that symlink will
> 	    become the default in future & asking for feedback if
> 	    --enable-i686-compat is not given
> 
>   * Step 2: symlink i686 binary by default but have --disable-i686-compat
>             to switch to full binary. Issue *WARNING* that full binary
> 	    will be soon removed if --disable-i686-compat is given
> 
>   * Step 3: remove full binary

Having said that, I guess this should still be expressed in a deprecation
note, if we rephase it to describe this plan.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|