From: Helge Deller <deller@gmx.de>
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 two 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) Remove the compile time checks in atomic.h because:
- for the qemu-system and qemu-user emulators this check is redundant
since we only allow 64-bit platforms anyway (see a)
- it breaks those 32-bit platforms, which do provide (slower) 64-bit atomics
- 32-bit platforms without 64-bit atomics will fail instead with linker errors
- the runtime speed of the qemu tools aren't actually that important.
I've sucessfully tested building qemu tools on 32-bit hppa.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
---
include/qemu/atomic.h | 16 ----------------
meson.build | 4 ++--
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index dc9290084b..f05dce36eb 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -56,14 +56,6 @@
*/
#define signal_barrier() __atomic_signal_fence(__ATOMIC_SEQ_CST)
-/*
- * 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
- * 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.
- */
-#define ATOMIC_REG_SIZE sizeof(void *)
-
/* Weak atomic operations prevent the compiler moving other
* loads/stores past the atomic operation load/store. However there is
* no explicit memory barrier for the processor.
@@ -79,7 +71,6 @@
#define qatomic_read(ptr) \
({ \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
qatomic_read__nocheck(ptr); \
})
@@ -87,7 +78,6 @@
__atomic_store_n(ptr, i, __ATOMIC_RELAXED)
#define qatomic_set(ptr, i) do { \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
qatomic_set__nocheck(ptr, i); \
} while(0)
@@ -110,7 +100,6 @@
*/
#define qatomic_rcu_read_internal(ptr, _val) \
({ \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
typeof_strip_qual(*ptr) _val; \
qatomic_rcu_read__nocheck(ptr, &_val); \
_val; \
@@ -119,20 +108,17 @@
qatomic_rcu_read_internal((ptr), MAKE_IDENTIFIER(_val))
#define qatomic_rcu_set(ptr, i) do { \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
__atomic_store_n(ptr, i, __ATOMIC_RELEASE); \
} while(0)
#define qatomic_load_acquire(ptr) \
({ \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
typeof_strip_qual(*ptr) _val; \
__atomic_load(ptr, &_val, __ATOMIC_ACQUIRE); \
_val; \
})
#define qatomic_store_release(ptr, i) do { \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
__atomic_store_n(ptr, i, __ATOMIC_RELEASE); \
} while(0)
@@ -144,7 +130,6 @@
})
#define qatomic_xchg(ptr, i) ({ \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
qatomic_xchg__nocheck(ptr, i); \
})
@@ -157,7 +142,6 @@
})
#define qatomic_cmpxchg(ptr, old, new) ({ \
- qemu_build_assert(sizeof(*ptr) <= ATOMIC_REG_SIZE); \
qatomic_cmpxchg__nocheck(ptr, old, new); \
})
diff --git a/meson.build b/meson.build
index daa58e46a3..98a708372b 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
--
2.47.3On 4/3/26 20:43, Michael Tokarev wrote: > From: Helge Deller <deller@gmx.de> > > 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 two 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) Remove the compile time checks in atomic.h because: > - for the qemu-system and qemu-user emulators this check is redundant > since we only allow 64-bit platforms anyway (see a) Nack. The assert is still useful on 64-bit hosts, because most but not all of our 64-bit hosts also have 128-bit atomics. We *shouldn't* be attempting atomics on Int128 (or structures) but you never know what'll slip in. > - it breaks those 32-bit platforms, which do provide (slower) 64-bit atomics > - 32-bit platforms without 64-bit atomics will fail instead with linker errors > - the runtime speed of the qemu tools aren't actually that important. > > I've sucessfully tested building qemu tools on 32-bit hppa. Well, i686, armv7, and m68k have 64-bit atomics in hardware. I see from gcc that hppa-linux has 64-bit atomics via syscall. I think testing got lucky. Other hosts, e.g. riscv32, I would expect to fail to link, per the second point above. Since the goal is tools, which do not have to interact atomically with guest emulation, we can fall back to libatomic. But that requires that we make the meson.build changes to actually link with libatomic. > -/* > - * 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 > - * 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. > - */ > -#define ATOMIC_REG_SIZE sizeof(void *) I think we should retain ATOMIC_REG_SIZE but use uint64_t not void*, and update the comment, noting atomic128.h as well. r~
On 4/4/26 01:49, Richard Henderson wrote: > On 4/3/26 20:43, Michael Tokarev wrote: >> - it breaks those 32-bit platforms, which do provide (slower) 64-bit >> atomics >> - 32-bit platforms without 64-bit atomics will fail instead with >> linker errors >> - the runtime speed of the qemu tools aren't actually that important. >> >> I've sucessfully tested building qemu tools on 32-bit hppa. > > Well, i686, armv7, and m68k have 64-bit atomics in hardware. > I see from gcc that hppa-linux has 64-bit atomics via syscall. > > I think testing got lucky. Other hosts, e.g. riscv32, I would expect to > fail to link, per the second point above. > > Since the goal is tools, which do not have to interact atomically with > guest emulation, we can fall back to libatomic. But that requires that > we make the meson.build changes to actually link with libatomic. I think we should just do the guest agent, and limit tools to 64-bit hosts. Paolo
On 04.04.2026 09:38, Paolo Bonzini wrote: > On 4/4/26 01:49, Richard Henderson wrote: >> Since the goal is tools, which do not have to interact atomically with >> guest emulation, we can fall back to libatomic. But that requires >> that we make the meson.build changes to actually link with libatomic. > I think we should just do the guest agent, and limit tools to 64-bit hosts. What's the prob with the tools on 32bit anyway? BTW, tools doesn't even use atomics, while qga does :) Thanks, /mjt
Il sab 4 apr 2026, 11:51 Michael Tokarev <mjt@tls.msk.ru> ha scritto: > On 04.04.2026 09:38, Paolo Bonzini wrote: > > On 4/4/26 01:49, Richard Henderson wrote: > > >> Since the goal is tools, which do not have to interact atomically with > >> guest emulation, we can fall back to libatomic. But that requires > >> that we make the meson.build changes to actually link with libatomic. > > I think we should just do the guest agent, and limit tools to 64-bit > hosts. > > What's the prob with the tools on 32bit anyway? > > BTW, tools doesn't even use atomics, while qga does :) > They do, and in fact Stat64 was removed as part of dropping 32-bit support. Tools share all the storage code with system emulation, which is way more complex than qga and would be mostly untested for 32-bit hosts. Paolo > Thanks, > > /mjt > >
Hi Paolo, On 4/4/26 13:03, Paolo Bonzini wrote: > Il sab 4 apr 2026, 11:51 Michael Tokarev <mjt@tls.msk.ru <mailto:mjt@tls.msk.ru>> ha scritto: > > On 04.04.2026 09:38, Paolo Bonzini wrote: > > On 4/4/26 01:49, Richard Henderson wrote: > > >> Since the goal is tools, which do not have to interact atomically with > >> guest emulation, we can fall back to libatomic. But that requires > >> that we make the meson.build changes to actually link with libatomic. > > I think we should just do the guest agent, and limit tools to 64-bit hosts. > > What's the prob with the tools on 32bit anyway? > > BTW, tools doesn't even use atomics, while qga does :) > > > They do, and in fact Stat64 was removed as part of dropping 32-bit support. Please note that debian (and probably other distributions still supporting 32-bit) enabled 64-bit file offsets, 64-bit time stamps and many other 64-bit flags by default, so there are actually no 32-bit limits/issues left on all 32-bit platforms beside i386/i686. > Tools share all the storage code with system emulation, which is way > more complex than qga and would be mostly untested for 32-bit hosts. I think nobody expects that the qemu team should officially test and support 32-bit hosts. Limiting official support to 64-bit is OK. The ask is simply to not actively *prevent* from being able to build and run on 32-bit hosts (or other unsupported architectures like m68k, powerpc, alpha, ...). Helge
Il sab 4 apr 2026, 13:50 Helge Deller <deller@gmx.de> ha scritto: > > They do, and in fact Stat64 was removed as part of dropping 32-bit > support. > > Please note that debian (and probably other distributions still supporting > 32-bit) > enabled 64-bit file offsets, 64-bit time stamps and many other 64-bit > flags by default, > so there are actually no 32-bit limits/issues left on all 32-bit platforms > beside i386/i686. It's not about limits, the problem is testing. Even if we don't provide official support we're still on the hook for fixing stuff, and for data losses caused by bugs. The maintenance can cost was the makn issue for TCG backends (but on the other hand something like x32, if it was still a thing, could be supported because the word length is 64 bits); but for the tools preventing from being able to build and run and lose data on 32-bit hosts is exactly the point. (By the way, for qemu-ga in 11.1 we'll probably support building it directly with meson+ninja, i.e. without passing through configure. This should be the main supported way to build qemu-ga only. Konstantin is doing it for MSVC support but we can make it the accepted way to build also on 32-bit hosts). Paolo > > Tools share all the storage code with system emulation, which is way > > more complex than qga and would be mostly untested for 32-bit hosts. > > I think nobody expects that the qemu team should officially test and > support 32-bit hosts. Limiting official support to 64-bit is OK. > > The ask is simply to not actively *prevent* from being able to build and > run > on 32-bit hosts (or other unsupported architectures like m68k, powerpc, > alpha, ...). > > Helge > >
© 2016 - 2026 Red Hat, Inc.