QEMU requires a 64-bit CPU host architecture?

QEMU requires a 64-bit CPU host architecture?

[Michael Tokarev]

Hi!

Is it intentional that qemu does not build utilities on 32bit hosts
anymore?

I understand system/user emulation on a 32bit host, where there are
quite some real difficulties with address space sizes.

But what's wrong with building qemu-img et al on a 32bit host?  It
doesn't require 64bit address space..

Thanks,

/mjt

Re: QEMU requires a 64-bit CPU host architecture?

[Daniel P. Berrangé]

On Fri, Mar 20, 2026 at 09:45:20AM +0300, Michael Tokarev wrote:
> Hi!
> 
> Is it intentional that qemu does not build utilities on 32bit hosts
> anymore?

Yes, per this note:

  https://www.qemu.org/docs/master/about/removed-features.html#bit-host-operating-systems-removed-in-11-0


> I understand system/user emulation on a 32bit host, where there are
> quite some real difficulties with address space sizes.
> 
> But what's wrong with building qemu-img et al on a 32bit host?  It
> doesn't require 64bit address space..

While the acclerator burden was one big factor, there were other
code removals enabled by dropping 32-bit hosts, such as removal
of 64-bit atomics emulation, and removal of some back compat
definitions for 32-bit kernels, and simplifying assumptions about
CPU features in other code, all of which leak out into common
code used by qemu-img & similar tools.

Keeping an arbitrary, and continually changing, subset of QEMU
supporting 32-bit while most code dropped 64-bit would not be
fun situation for maintainers, even with CI to try to detect
problems.

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

Re: QEMU requires a 64-bit CPU host architecture?

[Helge Deller]

On 3/20/26 09:54, Daniel P. Berrangé wrote:
> On Fri, Mar 20, 2026 at 09:45:20AM +0300, Michael Tokarev wrote:
>> Is it intentional that qemu does not build utilities on 32bit hosts
>> anymore?
> 
> Yes, per this note:
> 
>    https://www.qemu.org/docs/master/about/removed-features.html#bit-host-operating-systems-removed-in-11-0

This states:
"Keeping 32-bit *host support* alive was a substantial burden for the QEMU project. Thus QEMU dropped all support for all 32-bit host systems."

The parts of qemu which deal with running as emulator I agree with this (e.g. removal of atomic requirements and such as you stated below).

But Michael is referring to the *tools*, like qemu-img and such.
There is no need to limit those to 64-bit hosts.
Those tools are necessary on a lot of platforms and architectures,
not just those which are officially supported by qemu.
On Debian there are quite some hard dependencies of some debian packages
on the qemu tools to build other things.
I once had a debian bug report about this (which I would need to look up again).

That said, I strongly agree with Michael that we should not
pro-active prevent building the tools on 32-bit platforms (or
other architectures) and restore the ability to build (the tools only)
on 32-bit hosts again (even without official support).

Helge

>> I understand system/user emulation on a 32bit host, where there are
>> quite some real difficulties with address space sizes.
>>
>> But what's wrong with building qemu-img et al on a 32bit host?  It
>> doesn't require 64bit address space..
> 
> While the acclerator burden was one big factor, there were other
> code removals enabled by dropping 32-bit hosts, such as removal
> of 64-bit atomics emulation, and removal of some back compat
> definitions for 32-bit kernels, and simplifying assumptions about
> CPU features in other code, all of which leak out into common
> code used by qemu-img & similar tools.
> 
> Keeping an arbitrary, and continually changing, subset of QEMU
> supporting 32-bit while most code dropped 64-bit would not be
> fun situation for maintainers, even with CI to try to detect
> problems.
> 
> With regards,
> Daniel

Re: QEMU requires a 64-bit CPU host architecture?

[Michael Tokarev]

On 20.03.2026 09:45, Michael Tokarev wrote:
> Hi!
> 
> Is it intentional that qemu does not build utilities on 32bit hosts
> anymore?

This is

commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Thu Dec 18 09:56:27 2025 +1100

     meson: Reject 32-bit hosts

     32-bit hosts have been deprecated since 10.0.

How would one build qemu-img and especially qemu-guest-agent, say,
on i386 or armhf?

I tried removing this error message from meson.build (in $subject),
but it fails to build even the qga due to errors in atomic.h, -
even if these aren't used by qga.

That smells like a bad decision, - to drop qga and qemu-img support
on 32bit architectures.  Especially qga.

Thanks,

/mjt

Re: QEMU requires a 64-bit CPU host architecture?

[Daniel P. Berrangé]

On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote:
> On 20.03.2026 09:45, Michael Tokarev wrote:
> > Hi!
> > 
> > Is it intentional that qemu does not build utilities on 32bit hosts
> > anymore?
> 
> This is
> 
> commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
> Author: Richard Henderson <richard.henderson@linaro.org>
> Date:   Thu Dec 18 09:56:27 2025 +1100
> 
>     meson: Reject 32-bit hosts
> 
>     32-bit hosts have been deprecated since 10.0.
> 
> How would one build qemu-img and especially qemu-guest-agent, say,
> on i386 or armhf?
> 
> I tried removing this error message from meson.build (in $subject),
> but it fails to build even the qga due to errors in atomic.h, -
> even if these aren't used by qga.
> 
> That smells like a bad decision, - to drop qga and qemu-img support
> on 32bit architectures.  Especially qga.

IMHO dropping the block related tools is reasonable, as if you keep
that, the dependencies that need to remain 32-bit compatible ripple
out across a very large part of the codebase.

Not having qga though feels like a pretty undesirable consequence,
given our message overall is that we were dropping host support but
keeping 32-bit emulation.

IMHO, the qga probably ought to be a separate project, but it has
a core dependancy on the QAPI code generator, and some of the related
shared C code (qobject/, qapi/ and some parts of util/), but even that
is quite a tangled web of deps.

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

Re: QEMU requires a 64-bit CPU host architecture?

[Peter Maydell]

On Wed, 25 Mar 2026 at 09:19, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote:
> > On 20.03.2026 09:45, Michael Tokarev wrote:
> > > Hi!
> > >
> > > Is it intentional that qemu does not build utilities on 32bit hosts
> > > anymore?
> >
> > This is
> >
> > commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
> > Author: Richard Henderson <richard.henderson@linaro.org>
> > Date:   Thu Dec 18 09:56:27 2025 +1100
> >
> >     meson: Reject 32-bit hosts
> >
> >     32-bit hosts have been deprecated since 10.0.
> >
> > How would one build qemu-img and especially qemu-guest-agent, say,
> > on i386 or armhf?
> >
> > I tried removing this error message from meson.build (in $subject),
> > but it fails to build even the qga due to errors in atomic.h, -
> > even if these aren't used by qga.
> >
> > That smells like a bad decision, - to drop qga and qemu-img support
> > on 32bit architectures.  Especially qga.
>
> IMHO dropping the block related tools is reasonable, as if you keep
> that, the dependencies that need to remain 32-bit compatible ripple
> out across a very large part of the codebase.
>
> Not having qga though feels like a pretty undesirable consequence,
> given our message overall is that we were dropping host support but
> keeping 32-bit emulation.

Yes, I'm not sure we quite realised that we would be no longer
building QGA for 32-bits. How much effort would it be to
reinstate that?

-- PMM

Re: QEMU requires a 64-bit CPU host architecture?

[Philippe Mathieu-Daudé]

On 25/3/26 11:24, Peter Maydell wrote:
> On Wed, 25 Mar 2026 at 09:19, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote:
>>> On 20.03.2026 09:45, Michael Tokarev wrote:
>>>> Hi!
>>>>
>>>> Is it intentional that qemu does not build utilities on 32bit hosts
>>>> anymore?
>>>
>>> This is
>>>
>>> commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
>>> Author: Richard Henderson <richard.henderson@linaro.org>
>>> Date:   Thu Dec 18 09:56:27 2025 +1100
>>>
>>>      meson: Reject 32-bit hosts
>>>
>>>      32-bit hosts have been deprecated since 10.0.
>>>
>>> How would one build qemu-img and especially qemu-guest-agent, say,
>>> on i386 or armhf?
>>>
>>> I tried removing this error message from meson.build (in $subject),
>>> but it fails to build even the qga due to errors in atomic.h, -
>>> even if these aren't used by qga.
>>>
>>> That smells like a bad decision, - to drop qga and qemu-img support
>>> on 32bit architectures.  Especially qga.
>>
>> IMHO dropping the block related tools is reasonable, as if you keep
>> that, the dependencies that need to remain 32-bit compatible ripple
>> out across a very large part of the codebase.
>>
>> Not having qga though feels like a pretty undesirable consequence,
>> given our message overall is that we were dropping host support but
>> keeping 32-bit emulation.
> 
> Yes, I'm not sure we quite realised that we would be no longer
> building QGA for 32-bits. How much effort would it be to
> reinstate that?

 From the commits in 5053e0a65db...90e2e8ada7c we'd need to (partially)
revert various of the buildsys ones (meson & configure).

Then we'd need to check if the Stat64 API (90e2e8ada7c) was used by
the block tools, and if so also revert the atomic64 patches (around
997d86a9bb1). If not some (sane) refactor is needed for some core
components (disentangle qdev from qom due to the atomic uses). Still
we rely heavily on atomic helpers for threads and co-routines used
by the block layer (and also to reference the QOM objects...).

How / where would we test that (and for how long)?

Re: QEMU requires a 64-bit CPU host architecture?

[Daniel P. Berrangé]

On Wed, Mar 25, 2026 at 12:21:27PM +0100, Philippe Mathieu-Daudé wrote:
> On 25/3/26 11:24, Peter Maydell wrote:
> > On Wed, 25 Mar 2026 at 09:19, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > 
> > > On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote:
> > > > On 20.03.2026 09:45, Michael Tokarev wrote:
> > > > > Hi!
> > > > > 
> > > > > Is it intentional that qemu does not build utilities on 32bit hosts
> > > > > anymore?
> > > > 
> > > > This is
> > > > 
> > > > commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
> > > > Author: Richard Henderson <richard.henderson@linaro.org>
> > > > Date:   Thu Dec 18 09:56:27 2025 +1100
> > > > 
> > > >      meson: Reject 32-bit hosts
> > > > 
> > > >      32-bit hosts have been deprecated since 10.0.
> > > > 
> > > > How would one build qemu-img and especially qemu-guest-agent, say,
> > > > on i386 or armhf?
> > > > 
> > > > I tried removing this error message from meson.build (in $subject),
> > > > but it fails to build even the qga due to errors in atomic.h, -
> > > > even if these aren't used by qga.
> > > > 
> > > > That smells like a bad decision, - to drop qga and qemu-img support
> > > > on 32bit architectures.  Especially qga.
> > > 
> > > IMHO dropping the block related tools is reasonable, as if you keep
> > > that, the dependencies that need to remain 32-bit compatible ripple
> > > out across a very large part of the codebase.
> > > 
> > > Not having qga though feels like a pretty undesirable consequence,
> > > given our message overall is that we were dropping host support but
> > > keeping 32-bit emulation.
> > 
> > Yes, I'm not sure we quite realised that we would be no longer
> > building QGA for 32-bits. How much effort would it be to
> > reinstate that?
> 
> From the commits in 5053e0a65db...90e2e8ada7c we'd need to (partially)
> revert various of the buildsys ones (meson & configure).
> 
> Then we'd need to check if the Stat64 API (90e2e8ada7c) was used by
> the block tools, and if so also revert the atomic64 patches (around
> 997d86a9bb1). If not some (sane) refactor is needed for some core
> components (disentangle qdev from qom due to the atomic uses). Still
> we rely heavily on atomic helpers for threads and co-routines used
> by the block layer (and also to reference the QOM objects...).
> 
> How / where would we test that (and for how long)?

IMHO we should not re-enable the block layer for 32-bit. Beyond the
block/ directory, that also pulls in io/, crypto/, auth/, chardev/,
and implies both unit testing and I/O tests too.

I'd suggest we only make the guest agent work for 32-bit. aka
this command line:

 ./configure  --disable-system --disable-user --disable-tools --enable-guest-agent 

which limits us just to util/, qobject/, qapi/, qga/ dirs, and limited
unit tests only.

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

Re: QEMU requires a 64-bit CPU host architecture?

[Philippe Mathieu-Daudé]

On 25/3/26 12:21, Philippe Mathieu-Daudé wrote:
> On 25/3/26 11:24, Peter Maydell wrote:
>> On Wed, 25 Mar 2026 at 09:19, Daniel P. Berrangé <berrange@redhat.com> 
>> wrote:
>>>
>>> On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote:
>>>> On 20.03.2026 09:45, Michael Tokarev wrote:
>>>>> Hi!
>>>>>
>>>>> Is it intentional that qemu does not build utilities on 32bit hosts
>>>>> anymore?
>>>>
>>>> This is
>>>>
>>>> commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6
>>>> Author: Richard Henderson <richard.henderson@linaro.org>
>>>> Date:   Thu Dec 18 09:56:27 2025 +1100
>>>>
>>>>      meson: Reject 32-bit hosts
>>>>
>>>>      32-bit hosts have been deprecated since 10.0.
>>>>
>>>> How would one build qemu-img and especially qemu-guest-agent, say,
>>>> on i386 or armhf?
>>>>
>>>> I tried removing this error message from meson.build (in $subject),
>>>> but it fails to build even the qga due to errors in atomic.h, -
>>>> even if these aren't used by qga.
>>>>
>>>> That smells like a bad decision, - to drop qga and qemu-img support
>>>> on 32bit architectures.  Especially qga.
>>>
>>> IMHO dropping the block related tools is reasonable, as if you keep
>>> that, the dependencies that need to remain 32-bit compatible ripple
>>> out across a very large part of the codebase.
>>>
>>> Not having qga though feels like a pretty undesirable consequence,
>>> given our message overall is that we were dropping host support but
>>> keeping 32-bit emulation.
>>
>> Yes, I'm not sure we quite realised that we would be no longer
>> building QGA for 32-bits. How much effort would it be to
>> reinstate that?
> 
>  From the commits in 5053e0a65db...90e2e8ada7c we'd need to (partially)
> revert various of the buildsys ones (meson & configure).

Assuming this buildsys part, ...

> Then we'd need to check if the Stat64 API (90e2e8ada7c) was used by
> the block tools, and if so also revert the atomic64 patches (around
> 997d86a9bb1). If not some (sane) refactor is needed for some core
> components (disentangle qdev from qom due to the atomic uses). Still
> we rely heavily on atomic helpers for threads and co-routines used
> by the block layer (and also to reference the QOM objects...).

... then the single issue in QOM is the object_class_property_init_all()
(due to sysemu GlobalProperty) which can be stubbed, ...

... then the only problem left is what util/qsp.c defines:

- qemu_mutex_lock_func()
- qemu_cond_wait_func()
- qemu_cond_timedwait_func()

If we can provide a 32-bit version of these the qga links (not sure
it makes sense although).

> 
> How / where would we test that (and for how long)?

Re: QEMU requires a 64-bit CPU host architecture?

[Michael Tokarev]

On 25.03.2026 14:55, Philippe Mathieu-Daudé wrote:
...
> ... then the single issue in QOM is the object_class_property_init_all()
> (due to sysemu GlobalProperty) which can be stubbed, ...

qga doesn't actually need GlobalProperty, either.

> ... then the only problem left is what util/qsp.c defines:
> 
> - qemu_mutex_lock_func()
> - qemu_cond_wait_func()
> - qemu_cond_timedwait_func()
> 
> If we can provide a 32-bit version of these the qga links (not sure
> it makes sense although).

And these aren't needed - it seems - by qga either.

Both come to the qga link line using other, unrelated ways.

Thanks,

/mjt