[PATCH v3] Allow building qemu tools on 32-bit hosts

[PATCH v3] Allow building qemu tools on 32-bit hosts

[Helge Deller]

Qemu's tools like qemu-img are often needed on 32-bit platforms,
although the actual qemu emulators have been discontinued on 32-bit.

To allow building the tools on 32-bit this patch implements three small
changes:

a) The check in meson.build is changed to still error out if the user
tries to build qemu-system or qemu-user on a 32-bit platform, but allows
building tools (e.g. by "--enable-tools") alone.

b) The compile time check in atomic.h now checks against
sizeof(uint64_t) so that 32-bit environments can still build
successfully, while 128-bit atomic operations are prevented to sneak in.

c) Allow linking against libatomic as long as we don't build the
qemu-system and qemu-user binaries.

Sucessfully tested on the 32-bit big-endian powerpc architecture.

v2:
- keep comple time checks in atomic.h
- allow linking against libatomic when building tools

v3:
- Drop "-Wl,"
- added S-o-b

Signed-off-by: Helge Deller <deller@gmx.de>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index dc9290084b..e4dd948863 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -58,11 +58,11 @@
 
 /*
  * Sanity check that the size of an atomic operation isn't "overly large".
- * Despite the fact that e.g. i686 has 64-bit atomic operations, we do not
+ * Despite the fact that e.g. x86-64 has 128-bit atomic operations, we do not
  * want to use them because we ought not need them, and this lets us do a
- * bit of sanity checking that other 32-bit hosts might build.
+ * bit of sanity checking that other 32- and 64-bit hosts might build.
  */
-#define ATOMIC_REG_SIZE  sizeof(void *)
+#define ATOMIC_REG_SIZE  sizeof(uint64_t)
 
 /* Weak atomic operations prevent the compiler moving other
  * loads/stores past the atomic operation load/store. However there is
diff --git a/meson.build b/meson.build
index daa58e46a3..ab3e97eb9f 100644
--- a/meson.build
+++ b/meson.build
@@ -323,8 +323,8 @@ endif
 # Compiler flags #
 ##################
 
-if cc.sizeof('void *') < 8
-  error('QEMU requires a 64-bit CPU host architecture')
+if (cc.sizeof('void *') < 8) and (have_system or have_user)
+  error('QEMU emulator requires a 64-bit CPU host architecture. Only tools may be built for 32-bit.')
 endif
 
 foreach lang : all_languages
@@ -423,8 +423,16 @@ endif
 #
 # Later checks assume we won't get atomic ops for int128 without
 # explicitly asking for -latomic, so we must disable GCC's new
-# automatic linking with the new -fno-link-libatomic flag
-qemu_isa_flags += cc.get_supported_arguments('-fno-link-libatomic')
+# automatic linking with the new -fno-link-libatomic flag.
+#
+# When not building the emulators, but qemu helper tools only
+# (e.g. on 32-bit hosts), libatomic is sometimes required and
+# thus acceptable.
+if (have_system or have_user)
+  qemu_isa_flags += cc.get_supported_arguments('-fno-link-libatomic')
+else
+  qemu_ldflags += cc.get_supported_link_arguments('-latomic')
+endif
 
 qemu_common_flags = qemu_isa_flags + qemu_common_flags
 

Re: [PATCH v3] Allow building qemu tools on 32-bit hosts

[Daniel P. Berrangé]

On Sun, Apr 05, 2026 at 12:40:16AM +0200, Helge Deller wrote:
> Qemu's tools like qemu-img are often needed on 32-bit platforms,
> although the actual qemu emulators have been discontinued on 32-bit.

IMHO, the thought behind disabling 32-bit builds was not making
a statement about whether the code was useful on 32-bit platforms.
Users of 32-bit platforms will naturally always want to have as
much as possible available on their platform.

Rather it was that 32-bit platforms were no longer considered
important as targets by QEMU maintainers. The goal is thus to
reduce the set of targets that maintainers have to think about.

Thus the commit message needs to be justifying why 32-bit platforms
should still be treated as a target.

In terms of the impact on QEMU maintainers / subsystems we see

 * QEMU guest agent

    => util/, qapi/, qobject/, qom/, qga/

   Total about 300  C files

 * Adding in tools on top we also get

    => block/, chardev/, crypto/, io/, authz/, storage-daemon/

   Total about 700 C files


I'll support the build of QEMU guest agent on 32-bit, as we were
clear that we wanted to continue supporting 32-bit guests in
general.

I'm not in favour of re-introducing 32-bit support  for anything
else.

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: [PATCH v3] Allow building qemu tools on 32-bit hosts

[Michael Tokarev]

On 05.04.2026 01:40, Helge Deller wrote:
> Qemu's tools like qemu-img are often needed on 32-bit platforms,
> although the actual qemu emulators have been discontinued on 32-bit.
> 
> To allow building the tools on 32-bit this patch implements three small
> changes:
> 
> a) The check in meson.build is changed to still error out if the user
> tries to build qemu-system or qemu-user on a 32-bit platform, but allows
> building tools (e.g. by "--enable-tools") alone.
> 
> b) The compile time check in atomic.h now checks against
> sizeof(uint64_t) so that 32-bit environments can still build
> successfully, while 128-bit atomic operations are prevented to sneak in.
> 
> c) Allow linking against libatomic as long as we don't build the
> qemu-system and qemu-user binaries.
> 
> Sucessfully tested on the 32-bit big-endian powerpc architecture.

Hi!

Have you used just one additional fix for util/meson.build from me, or
all other changes from Philippe too?

I'm trying to verify if I can build qga and tools with just two patches
on 32bits, or if all of them are needed.

Changes by Philippe are really nice cleanups but I'm not sure they're
mandatory - when we're at -rc3 time..

Thanks,

/mjt

Re: [PATCH v3] Allow building qemu tools on 32-bit hosts

[Helge Deller]

On 4/7/26 17:12, Michael Tokarev wrote:
> On 05.04.2026 01:40, Helge Deller wrote:
>> Qemu's tools like qemu-img are often needed on 32-bit platforms,
>> although the actual qemu emulators have been discontinued on 32-bit.
>>
>> To allow building the tools on 32-bit this patch implements three small
>> changes:
>>
>> a) The check in meson.build is changed to still error out if the user
>> tries to build qemu-system or qemu-user on a 32-bit platform, but allows
>> building tools (e.g. by "--enable-tools") alone.
>>
>> b) The compile time check in atomic.h now checks against
>> sizeof(uint64_t) so that 32-bit environments can still build
>> successfully, while 128-bit atomic operations are prevented to sneak in.
>>
>> c) Allow linking against libatomic as long as we don't build the
>> qemu-system and qemu-user binaries.
>>
>> Sucessfully tested on the 32-bit big-endian powerpc architecture.
> 
> Hi!
> 
> Have you used just one additional fix for util/meson.build from me, or
> all other changes from Philippe too?

I used all...
  
> I'm trying to verify if I can build qga and tools with just two patches
> on 32bits, or if all of them are needed.

... but I didn't checked if the others were needed.

Helge

Re: [PATCH v3] Allow building qemu tools on 32-bit hosts

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Sun, Apr 05, 2026 at 12:40:16AM +0200, Helge Deller wrote:
>> Qemu's tools like qemu-img are often needed on 32-bit platforms,
>> although the actual qemu emulators have been discontinued on 32-bit.
>
> IMHO, the thought behind disabling 32-bit builds was not making
> a statement about whether the code was useful on 32-bit platforms.
> Users of 32-bit platforms will naturally always want to have as
> much as possible available on their platform.
>
> Rather it was that 32-bit platforms were no longer considered
> important as targets by QEMU maintainers. The goal is thus to
> reduce the set of targets that maintainers have to think about.
>
> Thus the commit message needs to be justifying why 32-bit platforms
> should still be treated as a target.
>
> In terms of the impact on QEMU maintainers / subsystems we see
>
>  * QEMU guest agent
>
>     => util/, qapi/, qobject/, qom/, qga/
>
>    Total about 300  C files
>
>  * Adding in tools on top we also get
>
>     => block/, chardev/, crypto/, io/, authz/, storage-daemon/
>
>    Total about 700 C files
>
>
> I'll support the build of QEMU guest agent on 32-bit, as we were
> clear that we wanted to continue supporting 32-bit guests in
> general.
>
> I'm not in favour of re-introducing 32-bit support  for anything
> else.

Neither am I.

Re: [PATCH v3] Allow building qemu tools on 32-bit hosts

[Peter Maydell]

On Mon, 13 Apr 2026 at 08:30, Markus Armbruster <armbru@redhat.com> wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Sun, Apr 05, 2026 at 12:40:16AM +0200, Helge Deller wrote:
> >> Qemu's tools like qemu-img are often needed on 32-bit platforms,
> >> although the actual qemu emulators have been discontinued on 32-bit.
> >
> > IMHO, the thought behind disabling 32-bit builds was not making
> > a statement about whether the code was useful on 32-bit platforms.
> > Users of 32-bit platforms will naturally always want to have as
> > much as possible available on their platform.
> >
> > Rather it was that 32-bit platforms were no longer considered
> > important as targets by QEMU maintainers. The goal is thus to
> > reduce the set of targets that maintainers have to think about.
> >
> > Thus the commit message needs to be justifying why 32-bit platforms
> > should still be treated as a target.
> >
> > In terms of the impact on QEMU maintainers / subsystems we see
> >
> >  * QEMU guest agent
> >
> >     => util/, qapi/, qobject/, qom/, qga/
> >
> >    Total about 300  C files
> >
> >  * Adding in tools on top we also get
> >
> >     => block/, chardev/, crypto/, io/, authz/, storage-daemon/
> >
> >    Total about 700 C files
> >
> >
> > I'll support the build of QEMU guest agent on 32-bit, as we were
> > clear that we wanted to continue supporting 32-bit guests in
> > general.
> >
> > I'm not in favour of re-introducing 32-bit support  for anything
> > else.
>
> Neither am I.

(NB that although I did take this patch into git, I did that
in order to preserve the status-quo for tools in 11.0, not as
a final answer to the decision of whether to support tools
for 32-bit.)

I think if one of our major downstream distributions wants
to re-add the 32-bit tool support then that strongly suggests
that we were a bit over-eager to remove it. 32-bit
emulation support is reasonable to drop because emulation
really does have to care about the 32/64 bit differences and
things like atomic instructions get much more painful.
The emulation parts are also by far the largest bit of our
CI workload.

But the tools should be "just normal C code" and supporting
32-bit there should not require anything beyond the bounds
of normal write-portable-code concerns. And a test run that
is only building testing tools should be a small part of our
CI usage.

thanks
-- PMM