accel/accel-system.c | 1 + backends/hostmem.c | 1 + hw/core/machine.c | 1 + hw/core/qdev-properties.c | 1 + hw/core/qdev.c | 1 + hw/i386/pc_q35.c | 1 + include/hw/core/boards.h | 11 +++ include/hw/core/qdev-properties.h | 1 + include/hw/core/qdev.h | 27 ------- include/qemu/atomic.h | 16 ----- include/qom/compat-properties.h | 40 +++++++++++ include/qom/object.h | 8 --- meson.build | 4 +- qom/compat-properties.c | 116 ++++++++++++++++++++++++++++++ qom/meson.build | 3 + qom/object.c | 102 +------------------------- system/rtc.c | 1 + system/vl.c | 1 + target/i386/sev.c | 1 + ui/vdagent.c | 1 + util/meson.build | 6 +- 21 files changed, 187 insertions(+), 157 deletions(-) create mode 100644 include/qom/compat-properties.h create mode 100644 qom/compat-properties.c
This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd buildable on 32bit hosts again. The patches are simple enough to be picked up for 11.0. The one from Helge is marked as RFC still, but I'd love for it to be accepted the way it is. All patches has been on qemu-devel previously, I just collected them into a single batch. Helge Deller (1): RFC: Allow building qemu tools on 32-bit hosts Michael Tokarev (1): util/meson.build: do not add cpuinfo-$arch to util_ss for 32bit CPUs Philippe Mathieu-Daudé (4): hw/core: Move compat_props_add() to 'hw/core/boards.h' qom: Declare GlobalProperty structure in 'qom/compat-properties.h' qom: Declare compat properties API in 'qom/compat-properties.h' qom: Restrict compat properties API to system emulation accel/accel-system.c | 1 + backends/hostmem.c | 1 + hw/core/machine.c | 1 + hw/core/qdev-properties.c | 1 + hw/core/qdev.c | 1 + hw/i386/pc_q35.c | 1 + include/hw/core/boards.h | 11 +++ include/hw/core/qdev-properties.h | 1 + include/hw/core/qdev.h | 27 ------- include/qemu/atomic.h | 16 ----- include/qom/compat-properties.h | 40 +++++++++++ include/qom/object.h | 8 --- meson.build | 4 +- qom/compat-properties.c | 116 ++++++++++++++++++++++++++++++ qom/meson.build | 3 + qom/object.c | 102 +------------------------- system/rtc.c | 1 + system/vl.c | 1 + target/i386/sev.c | 1 + ui/vdagent.c | 1 + util/meson.build | 6 +- 21 files changed, 187 insertions(+), 157 deletions(-) create mode 100644 include/qom/compat-properties.h create mode 100644 qom/compat-properties.c -- 2.47.3
On 3/4/26 12:43, Michael Tokarev wrote: > This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd > buildable on 32bit hosts again. The patches are simple enough to be > picked up for 11.0. The one from Helge is marked as RFC still, but > I'd love for it to be accepted the way it is. v11.0.0-rc2 is already out, these look (in particular the atomic patch) too late to me. Is it doable distributions use v9.2 for qemu-guest-agent / qemu-img / qemu-nbd on 32-bit hosts?
On 03.04.2026 18:33, Philippe Mathieu-Daudé wrote: > On 3/4/26 12:43, Michael Tokarev wrote: >> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd >> buildable on 32bit hosts again. The patches are simple enough to be >> picked up for 11.0. The one from Helge is marked as RFC still, but >> I'd love for it to be accepted the way it is. > > v11.0.0-rc2 is already out, these look (in particular the atomic patch) > too late to me. I don't see a problem with applying atomics change to 11.0. It is just removing asserts because they're really useless - on 64bit platforms we do have all necessary atomics. If that sounds too risky, we can add a meson check for atomics if a system or user build is requested. > Is it doable distributions use v9.2 for qemu-guest-agent / qemu-img / > qemu-nbd on 32-bit hosts? Guess you mean 10.2. Nope, it's easier than that: if this patchset isn't accepted upstream for 11.0, I'll include it in debian. See https://salsa.debian.org/qemu-team/qemu/-/tree/experimental/debian/patches/32bit?ref_type=heads -- this is what I uploaded a few minutes ago. Hopefully it builds on all 32bit platforms too. Using 10.2 is.. not easy. Thanks, /mjt
On 4/3/26 17:40, Michael Tokarev wrote: > On 03.04.2026 18:33, Philippe Mathieu-Daudé wrote: >> On 3/4/26 12:43, Michael Tokarev wrote: >>> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd >>> buildable on 32bit hosts again. The patches are simple enough to be >>> picked up for 11.0. The one from Helge is marked as RFC still, but >>> I'd love for it to be accepted the way it is. >> >> v11.0.0-rc2 is already out, these look (in particular the atomic patch) >> too late to me. > > I don't see a problem with applying atomics change to 11.0. It is just > removing asserts because they're really useless - on 64bit platforms we > do have all necessary atomics. Correct. Like Michael, I suggest we include this patch series into v11 as well. > If that sounds too risky, we can add a meson check for atomics if a > system or user build is requested. Isn't that what the second hunk in my patch already does? >> Is it doable distributions use v9.2 for qemu-guest-agent / qemu-img / >> qemu-nbd on 32-bit hosts? > > Guess you mean 10.2. Nope, it's easier than that: if this patchset > isn't accepted upstream for 11.0, I'll include it in debian. See > https://salsa.debian.org/qemu-team/qemu/-/tree/experimental/debian/patches/32bit?ref_type=heads -- > this is what I uploaded a few minutes ago. Hopefully it builds on all > 32bit platforms too. > > Using 10.2 is.. not easy. Right. Helge
On 03.04.2026 18:56, Helge Deller wrote: > On 4/3/26 17:40, Michael Tokarev wrote: .. >> I don't see a problem with applying atomics change to 11.0. It is just >> removing asserts because they're really useless - on 64bit platforms we >> do have all necessary atomics. > > Correct. > Like Michael, I suggest we include this patch series into v11 as well. > >> If that sounds too risky, we can add a meson check for atomics if a >> system or user build is requested. > > Isn't that what the second hunk in my patch already does? Actually yes. The whole compile-time atomics test is completely unnecessary now for system or user emulation, there's nothing else needed. We only relax the sizeof(void*) check in meson to enforce it in system- or user-mode only, without affecting tools build, and that's all. This change does not affect system- or user- builds at all, it just allows tools-only build on 32bit hosts instead of disallowing it entirely. I think it's definitely a progress. If tools-only build on 32bit is found broken in 11.0 final, we'll fix it in 11.0.1, - it's not a big deal (and I think I'll know it very soon when this patchset finishes building on debian). A much bigger deal is if we don't have that stuff buildable on 32bits at all. IMHO anyway. Thanks, /mjt
Michael Tokarev <mjt@tls.msk.ru> writes:
> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd
> buildable on 32bit hosts again. The patches are simple enough to be
> picked up for 11.0. The one from Helge is marked as RFC still, but
> I'd love for it to be accepted the way it is.
>
> All patches has been on qemu-devel previously, I just collected them
> into a single batch.
How are you configuring the 32bit build. I'm trying:
'../../configure' '--disable-docs' '--disable-system' '--disable-user' '--cross-prefix=i686-linux-gnu-'
but failing with:
Command line: `i686-linux-gnu-gcc -m64 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c -o /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/output.obj -c -pthread -D_FILE_OFFSET_BITS=64 -O0 -std=gnu11` -> 1
stderr:
/home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c: In function 'main':
/home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c:6:16: error: size of array 'qemu_build_bug_on' is negative
6 | typedef char qemu_build_bug_on[(x)?-1:1] __attribute__((unused));
| ^~~~~~~~~~~~~~~~~
/home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c:9:6: note: in expansion of macro 'QEMU_BUILD_BUG_ON'
9 | QEMU_BUILD_BUG_ON(sizeof(size_t) != GLIB_SIZEOF_SIZE_T);
| ^~~~~~~~~~~~~~~~~
-----------
../../meson.build:1072:2: ERROR: Problem encountered: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
You probably need to set PKG_CONFIG_LIBDIR" to point
to the right pkg-config files for your build target.
I've pointed PKG_CONFIG_LIBDIR at the right place I think:
➜ echo $PKG_CONFIG_LIBDIR
/usr/lib/i386-linux-gnu/pkgconfig
🕙20:02:58 alex@draig:qemu.git/builds/testing on 20260403_mjt_tls_msk_ru [$?]
➜ pkg-config --path glib-2.0
/usr/lib/i386-linux-gnu/pkgconfig//glib-2.0.pc
But obviously I must be holding it wrong.
>
> Helge Deller (1):
> RFC: Allow building qemu tools on 32-bit hosts
>
> Michael Tokarev (1):
> util/meson.build: do not add cpuinfo-$arch to util_ss for 32bit CPUs
>
> Philippe Mathieu-Daudé (4):
> hw/core: Move compat_props_add() to 'hw/core/boards.h'
> qom: Declare GlobalProperty structure in 'qom/compat-properties.h'
> qom: Declare compat properties API in 'qom/compat-properties.h'
> qom: Restrict compat properties API to system emulation
>
> accel/accel-system.c | 1 +
> backends/hostmem.c | 1 +
> hw/core/machine.c | 1 +
> hw/core/qdev-properties.c | 1 +
> hw/core/qdev.c | 1 +
> hw/i386/pc_q35.c | 1 +
> include/hw/core/boards.h | 11 +++
> include/hw/core/qdev-properties.h | 1 +
> include/hw/core/qdev.h | 27 -------
> include/qemu/atomic.h | 16 -----
> include/qom/compat-properties.h | 40 +++++++++++
> include/qom/object.h | 8 ---
> meson.build | 4 +-
> qom/compat-properties.c | 116 ++++++++++++++++++++++++++++++
> qom/meson.build | 3 +
> qom/object.c | 102 +-------------------------
> system/rtc.c | 1 +
> system/vl.c | 1 +
> target/i386/sev.c | 1 +
> ui/vdagent.c | 1 +
> util/meson.build | 6 +-
> 21 files changed, 187 insertions(+), 157 deletions(-)
> create mode 100644 include/qom/compat-properties.h
> create mode 100644 qom/compat-properties.c
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Hi Alex, On 4/4/26 21:03, Alex Bennée wrote: > Michael Tokarev <mjt@tls.msk.ru> writes: > >> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd >> buildable on 32bit hosts again. The patches are simple enough to be >> picked up for 11.0. The one from Helge is marked as RFC still, but >> I'd love for it to be accepted the way it is. >> >> All patches has been on qemu-devel previously, I just collected them >> into a single batch. > > How are you configuring the 32bit build. I'm trying: > > '../../configure' '--disable-docs' '--disable-system' '--disable-user' '--cross-prefix=i686-linux-gnu-' Basically that's the command line, but I'm in a native chroot/physical box, so I didn't need the --cross-prefix option. > but failing with: > > Command line: `i686-linux-gnu-gcc -m64 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c -o /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/output.obj -c -pthread -D_FILE_OFFSET_BITS=64 -O0 -std=gnu11` -> 1 > stderr: > /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c: In function 'main': > /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c:6:16: error: size of array 'qemu_build_bug_on' is negative > 6 | typedef char qemu_build_bug_on[(x)?-1:1] __attribute__((unused)); > | ^~~~~~~~~~~~~~~~~ > /home/alex/lsrc/qemu.git/builds/testing/meson-private/tmpp4ra9pn_/testfile.c:9:6: note: in expansion of macro 'QEMU_BUILD_BUG_ON' > 9 | QEMU_BUILD_BUG_ON(sizeof(size_t) != GLIB_SIZEOF_SIZE_T); > | ^~~~~~~~~~~~~~~~~ > ----------- > > ../../meson.build:1072:2: ERROR: Problem encountered: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T. > You probably need to set PKG_CONFIG_LIBDIR" to point > to the right pkg-config files for your build target. > > I've pointed PKG_CONFIG_LIBDIR at the right place I think: > > ➜ echo $PKG_CONFIG_LIBDIR > /usr/lib/i386-linux-gnu/pkgconfig > 🕙20:02:58 alex@draig:qemu.git/builds/testing on 20260403_mjt_tls_msk_ru [$?] > ➜ pkg-config --path glib-2.0 > /usr/lib/i386-linux-gnu/pkgconfig//glib-2.0.pc > > But obviously I must be holding it wrong. Of course all libraries, including glib, would need to have been built for 64-bit. On Debian esp. i386 has been excluded from the 64-bit time_t transition because its primary use case is running legacy 32-bit binaries, and that would no longer be possible following an ABI change. See [1]. [1] https://wiki.debian.org/ReleaseGoals/64bit-time I assume your i386-libs still use 32-bit time_t. As debian developer it's possible to use the debian porterboxes. Or, as qemu developer, you could simply set up a debian chroot with linux-user for armhf, m68k, hppa, powerpc or sh4, e.g. a=powerpc && debootstrap --arch=$a --include=busybox --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid $a-chroot http://ftp.ports.debian.org/debian-ports/ cd /etc && cp passwd group shells $a-chroot/etc echo $a-chroot > $a-chroot/etc/debian_chroot Helge
On 04.04.2026 22:03, Alex Bennée wrote: > Michael Tokarev <mjt@tls.msk.ru> writes: > >> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd >> buildable on 32bit hosts again. The patches are simple enough to be >> picked up for 11.0. The one from Helge is marked as RFC still, but >> I'd love for it to be accepted the way it is. >> >> All patches has been on qemu-devel previously, I just collected them >> into a single batch. > > How are you configuring the 32bit build. I'm trying: > > '../../configure' '--disable-docs' '--disable-system' '--disable-user' '--cross-prefix=i686-linux-gnu-' > > but failing with: > > Command line: `i686-linux-gnu-gcc -m64 -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/ > 9 | QEMU_BUILD_BUG_ON(sizeof(size_t) != GLIB_SIZEOF_SIZE_T); > | ^~~~~~~~~~~~~~~~~ Umm. This is all mixed up. -m64? -I/usr/include/glib-2.0 goes before -I/usr/lib/i386...glib/ ? You should have glib-dev:i386 and pkgconf:i386, I guess. But I never tried to build it on my regular environment. I only built it by sbuild (either --arch=i386 or --host=i386), or on a porterbox. Though, I just tried to build for --host=armhf on an amd64 chroot, and it worked too. This is all about debian. I don't know how it all works on other distributions. Thanks, /mjt
On 05.04.2026 20:46, Michael Tokarev wrote: > On 04.04.2026 22:03, Alex Bennée wrote: >> Michael Tokarev <mjt@tls.msk.ru> writes: >> >>> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd >>> buildable on 32bit hosts again. The patches are simple enough to be >>> picked up for 11.0. The one from Helge is marked as RFC still, but >>> I'd love for it to be accepted the way it is. >>> >>> All patches has been on qemu-devel previously, I just collected them >>> into a single batch. >> >> How are you configuring the 32bit build. I'm trying: >> >> '../../configure' '--disable-docs' '--disable-system' '--disable- >> user' '--cross-prefix=i686-linux-gnu-' >> >> but failing with: >> >> Command line: `i686-linux-gnu-gcc -m64 -I/usr/include/glib-2.0 -I/ >> usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/ > > >> 9 | QEMU_BUILD_BUG_ON(sizeof(size_t) != GLIB_SIZEOF_SIZE_T); >> | ^~~~~~~~~~~~~~~~~ > > Umm. This is all mixed up. > > -m64? > -I/usr/include/glib-2.0 goes before -I/usr/lib/i386...glib/ ? I see what's going on. ./configure ... ... WARNING: unrecognized host CPU, proceeding with 'uname -m' output 'x86_64' And it use i686-linux-gnu-gcc -m64 due to this. And everything's screwed up from this point on. I haven't looked at this in more details, but that's the key point. It is qemu's ./configure which does the wrong here. Or the right, depending on your PoV - for qemu, i386 is an unsupported cpu entirely. Thanks, /mjt
On Tue, 7 Apr 2026 at 20:19, Michael Tokarev <mjt@tls.msk.ru> wrote: > > On 05.04.2026 20:46, Michael Tokarev wrote: > > On 04.04.2026 22:03, Alex Bennée wrote: > >> Michael Tokarev <mjt@tls.msk.ru> writes: > >> > >>> This is a patchset which makes qemu-guest-agent, qemu-img & qemu-nbd > >>> buildable on 32bit hosts again. The patches are simple enough to be > >>> picked up for 11.0. The one from Helge is marked as RFC still, but > >>> I'd love for it to be accepted the way it is. > >>> > >>> All patches has been on qemu-devel previously, I just collected them > >>> into a single batch. > >> > >> How are you configuring the 32bit build. I'm trying: > >> > >> '../../configure' '--disable-docs' '--disable-system' '--disable- > >> user' '--cross-prefix=i686-linux-gnu-' > >> > >> but failing with: > >> > >> Command line: `i686-linux-gnu-gcc -m64 -I/usr/include/glib-2.0 -I/ > >> usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/ > > > > > >> 9 | QEMU_BUILD_BUG_ON(sizeof(size_t) != GLIB_SIZEOF_SIZE_T); > >> | ^~~~~~~~~~~~~~~~~ > > > > Umm. This is all mixed up. > > > > -m64? > > -I/usr/include/glib-2.0 goes before -I/usr/lib/i386...glib/ ? > > I see what's going on. > > ./configure ... > ... > WARNING: unrecognized host CPU, proceeding with 'uname -m' output 'x86_64' > > And it use i686-linux-gnu-gcc -m64 due to this. And everything's > screwed up from this point on. > > I haven't looked at this in more details, but that's the key point. > It is qemu's ./configure which does the wrong here. Or the right, > depending on your PoV - for qemu, i386 is an unsupported cpu > entirely. You can override that guess by passing '--cpu=<whatever>'. Really we ought to remove that "guess based on uname" code path entirely and require anybody whose CPU type we don't guess to specify the architecture. -- PMM
© 2016 - 2026 Red Hat, Inc.