| Message ID | 20250203031821.741477-1-richard.henderson@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | meson: Deprecate 32-bit host support | expand |
On 2/3/25 04:18, Richard Henderson wrote: > v1: 20250128004254.33442-1-richard.henderson@linaro.org > > For v2, immediately disable 64-on-32 TCG. > > I *suspect* that we should disable 64-on-32 for *all* accelerators. > The idea that an i686 binary on an x86_64 host may be used to spawn > an x86_64 guest via kvm is silly and a bit more than niche. At least Xen used to be commonly used with 32-bit dom0, because it saved memory and dom0 would map in guest buffers as needed. I'm not sure how common that is these days, perhaps Stefano knows. For KVM however I don't think anyone cares. Paolo > Similarly for mips32 spawning mips64 and ppc32 spawning ppc64. > > But in the meantime, jump through a couple of hoops to keep these > kvm and xen cases building, while disabling tcg in the same binaries. > > > Richard Henderson (14): > meson: Drop tcg as a module > tcg: Move stubs in tcg/perf.h to tcg/perf-stubs.c > plugins: Uninline qemu_plugin_add_opts > meson: Introduce CONFIG_TCG_TARGET > tcg: Link only when required in system mode > plugins: Link only when required in system mode > accel/stubs: Expand stubs for TCG > target/mips: Protect objects with CONFIG_TCG > gitlab: Replace aarch64 with arm in cross-i686-tci build > configure: Define TARGET_LONG_BITS in configs/targets/*.mak > target/*: Remove TARGET_LONG_BITS from cpu-param.h > meson: Disallow 64-bit on 32-bit TCG emulation > meson: Deprecate 32-bit host support > tcg: Remove TCG_OVERSIZED_GUEST > > include/qemu/atomic.h | 18 ++------ > include/qemu/osdep.h | 7 +++ > include/qemu/plugin.h | 9 +--- > include/tcg/oversized-guest.h | 23 ---------- > include/tcg/perf.h | 23 ---------- > target/alpha/cpu-param.h | 2 - > target/arm/cpu-param.h | 2 - > target/avr/cpu-param.h | 1 - > target/hexagon/cpu-param.h | 1 - > target/hppa/cpu-param.h | 2 - > target/i386/cpu-param.h | 2 - > target/loongarch/cpu-param.h | 1 - > target/m68k/cpu-param.h | 1 - > target/microblaze/cpu-param.h | 2 - > target/mips/cpu-param.h | 5 --- > target/openrisc/cpu-param.h | 1 - > target/ppc/cpu-param.h | 2 - > target/riscv/cpu-param.h | 2 - > target/rx/cpu-param.h | 1 - > target/s390x/cpu-param.h | 1 - > target/sh4/cpu-param.h | 1 - > target/sparc/cpu-param.h | 2 - > target/tricore/cpu-param.h | 1 - > target/xtensa/cpu-param.h | 1 - > accel/stubs/tcg-stub.c | 24 ++++++++++ > accel/tcg/cputlb.c | 7 --- > accel/tcg/tcg-all.c | 9 ++-- > plugins/loader.c | 7 ++- > plugins/stubs.c | 49 +++++++++++++++++++++ > target/arm/ptw.c | 34 -------------- > target/riscv/cpu_helper.c | 13 +----- > tcg/perf-stubs.c | 26 +++++++++++ > .gitlab-ci.d/crossbuilds.yml | 2 +- > accel/tcg/meson.build | 11 ++--- > configs/targets/aarch64-bsd-user.mak | 1 + > configs/targets/aarch64-linux-user.mak | 1 + > configs/targets/aarch64-softmmu.mak | 1 + > configs/targets/aarch64_be-linux-user.mak | 1 + > configs/targets/alpha-linux-user.mak | 1 + > configs/targets/alpha-softmmu.mak | 1 + > configs/targets/arm-bsd-user.mak | 1 + > configs/targets/arm-linux-user.mak | 1 + > configs/targets/arm-softmmu.mak | 1 + > configs/targets/armeb-linux-user.mak | 1 + > configs/targets/avr-softmmu.mak | 1 + > configs/targets/hexagon-linux-user.mak | 1 + > configs/targets/hppa-linux-user.mak | 2 + > configs/targets/hppa-softmmu.mak | 1 + > configs/targets/i386-bsd-user.mak | 1 + > configs/targets/i386-linux-user.mak | 1 + > configs/targets/i386-softmmu.mak | 1 + > configs/targets/loongarch64-linux-user.mak | 1 + > configs/targets/loongarch64-softmmu.mak | 1 + > configs/targets/m68k-linux-user.mak | 1 + > configs/targets/m68k-softmmu.mak | 1 + > configs/targets/microblaze-linux-user.mak | 1 + > configs/targets/microblaze-softmmu.mak | 3 ++ > configs/targets/microblazeel-linux-user.mak | 1 + > configs/targets/microblazeel-softmmu.mak | 3 ++ > configs/targets/mips-linux-user.mak | 1 + > configs/targets/mips-softmmu.mak | 1 + > configs/targets/mips64-linux-user.mak | 1 + > configs/targets/mips64-softmmu.mak | 1 + > configs/targets/mips64el-linux-user.mak | 1 + > configs/targets/mips64el-softmmu.mak | 1 + > configs/targets/mipsel-linux-user.mak | 1 + > configs/targets/mipsel-softmmu.mak | 1 + > configs/targets/mipsn32-linux-user.mak | 1 + > configs/targets/mipsn32el-linux-user.mak | 1 + > configs/targets/or1k-linux-user.mak | 1 + > configs/targets/or1k-softmmu.mak | 1 + > configs/targets/ppc-linux-user.mak | 1 + > configs/targets/ppc-softmmu.mak | 1 + > configs/targets/ppc64-linux-user.mak | 1 + > configs/targets/ppc64-softmmu.mak | 1 + > configs/targets/ppc64le-linux-user.mak | 1 + > configs/targets/riscv32-linux-user.mak | 1 + > configs/targets/riscv32-softmmu.mak | 1 + > configs/targets/riscv64-bsd-user.mak | 1 + > configs/targets/riscv64-linux-user.mak | 1 + > configs/targets/riscv64-softmmu.mak | 1 + > configs/targets/rx-softmmu.mak | 1 + > configs/targets/s390x-linux-user.mak | 1 + > configs/targets/s390x-softmmu.mak | 1 + > configs/targets/sh4-linux-user.mak | 1 + > configs/targets/sh4-softmmu.mak | 1 + > configs/targets/sh4eb-linux-user.mak | 1 + > configs/targets/sh4eb-softmmu.mak | 1 + > configs/targets/sparc-linux-user.mak | 1 + > configs/targets/sparc-softmmu.mak | 1 + > configs/targets/sparc32plus-linux-user.mak | 1 + > configs/targets/sparc64-linux-user.mak | 1 + > configs/targets/sparc64-softmmu.mak | 1 + > configs/targets/tricore-softmmu.mak | 1 + > configs/targets/x86_64-bsd-user.mak | 1 + > configs/targets/x86_64-linux-user.mak | 1 + > configs/targets/x86_64-softmmu.mak | 1 + > configs/targets/xtensa-linux-user.mak | 1 + > configs/targets/xtensa-softmmu.mak | 1 + > configs/targets/xtensaeb-linux-user.mak | 1 + > configs/targets/xtensaeb-softmmu.mak | 1 + > docs/about/deprecated.rst | 7 +++ > docs/devel/multi-thread-tcg.rst | 1 - > meson.build | 47 +++++++++----------- > plugins/meson.build | 5 ++- > target/mips/tcg/meson.build | 4 +- > target/mips/tcg/system/meson.build | 6 +-- > tcg/meson.build | 8 +++- > 108 files changed, 241 insertions(+), 202 deletions(-) > delete mode 100644 include/tcg/oversized-guest.h > create mode 100644 plugins/stubs.c > create mode 100644 tcg/perf-stubs.c >
On 2/3/25 04:54, Paolo Bonzini wrote: > On 2/3/25 04:18, Richard Henderson wrote: >> v1: 20250128004254.33442-1-richard.henderson@linaro.org >> >> For v2, immediately disable 64-on-32 TCG. >> >> I *suspect* that we should disable 64-on-32 for *all* accelerators. >> The idea that an i686 binary on an x86_64 host may be used to spawn >> an x86_64 guest via kvm is silly and a bit more than niche. > > At least Xen used to be commonly used with 32-bit dom0, because it saved memory and dom0 > would map in guest buffers as needed. I'm not sure how common that is these days, perhaps > Stefano knows. As a data-point, debian does not ship libxen-dev for i686. We cannot build-test this configuration at all. I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for an armhf host, or as an armhf binary running on an aarch64 host. r~
+Xen maintainers On Mon, 3 Feb 2025, Richard Henderson wrote: > On 2/3/25 04:54, Paolo Bonzini wrote: > > On 2/3/25 04:18, Richard Henderson wrote: > > > v1: 20250128004254.33442-1-richard.henderson@linaro.org > > > > > > For v2, immediately disable 64-on-32 TCG. > > > > > > I *suspect* that we should disable 64-on-32 for *all* accelerators. > > > The idea that an i686 binary on an x86_64 host may be used to spawn > > > an x86_64 guest via kvm is silly and a bit more than niche. > > > > At least Xen used to be commonly used with 32-bit dom0, because it saved > > memory and dom0 would map in guest buffers as needed. I'm not sure how > > common that is these days, perhaps Stefano knows. > > As a data-point, debian does not ship libxen-dev for i686. > We cannot build-test this configuration at all. > > I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's > unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for > an armhf host, or as an armhf binary running on an aarch64 host. On the Xen side, there are two different use cases: x86 32-bit and ARM 32-bit. For x86 32-bit, while it was a very important use case in the past, I believe it is far less so now. I will let the x86 maintainers comment on how important it is today. For ARM 32-bit, I do not think we ever had many deployments, as most are 64-bit. Even when there are deployments, they do not typically use QEMU, as QEMU is less important for Xen on ARM compared to x86. Therefore, I would not block your cleanup and deprecation because of that. I will let the other ARM maintainers chime in.
On Mon, Feb 03, 2025 at 02:43:05PM -0800, Stefano Stabellini wrote: > +Xen maintainers > > > On Mon, 3 Feb 2025, Richard Henderson wrote: > > On 2/3/25 04:54, Paolo Bonzini wrote: > > > On 2/3/25 04:18, Richard Henderson wrote: > > > > v1: 20250128004254.33442-1-richard.henderson@linaro.org > > > > > > > > For v2, immediately disable 64-on-32 TCG. > > > > > > > > I *suspect* that we should disable 64-on-32 for *all* accelerators. > > > > The idea that an i686 binary on an x86_64 host may be used to spawn > > > > an x86_64 guest via kvm is silly and a bit more than niche. > > > > > > At least Xen used to be commonly used with 32-bit dom0, because it saved > > > memory and dom0 would map in guest buffers as needed. I'm not sure how > > > common that is these days, perhaps Stefano knows. > > > > As a data-point, debian does not ship libxen-dev for i686. > > We cannot build-test this configuration at all. > > > > I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's > > unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for > > an armhf host, or as an armhf binary running on an aarch64 host. > > > On the Xen side, there are two different use cases: x86 32-bit and ARM > 32-bit. > > For x86 32-bit, while it was a very important use case in the past, I > believe it is far less so now. I will let the x86 maintainers comment on > how important it is today. If the Xen project needs an excuse to justify stopping 32-bit host support, QEMU would be happy to act as the excuse :-) With regards, Daniel
On 03.02.25 23:43, Stefano Stabellini wrote: > +Xen maintainers > > > On Mon, 3 Feb 2025, Richard Henderson wrote: >> On 2/3/25 04:54, Paolo Bonzini wrote: >>> On 2/3/25 04:18, Richard Henderson wrote: >>>> v1: 20250128004254.33442-1-richard.henderson@linaro.org >>>> >>>> For v2, immediately disable 64-on-32 TCG. >>>> >>>> I *suspect* that we should disable 64-on-32 for *all* accelerators. >>>> The idea that an i686 binary on an x86_64 host may be used to spawn >>>> an x86_64 guest via kvm is silly and a bit more than niche. >>> >>> At least Xen used to be commonly used with 32-bit dom0, because it saved >>> memory and dom0 would map in guest buffers as needed. I'm not sure how >>> common that is these days, perhaps Stefano knows. >> >> As a data-point, debian does not ship libxen-dev for i686. >> We cannot build-test this configuration at all. >> >> I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's >> unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for >> an armhf host, or as an armhf binary running on an aarch64 host. > > > On the Xen side, there are two different use cases: x86 32-bit and ARM > 32-bit. > > For x86 32-bit, while it was a very important use case in the past, I > believe it is far less so now. I will let the x86 maintainers comment on > how important it is today. As dom0 on x86 is a PV guest per default and Linux doesn't support running as a 32-bit PV guest since a few years now, I guess there is no need to support qemu as 32-bit on x86 for Xen. Juergen
On 04.02.2025 09:19, Juergen Gross wrote: > On 03.02.25 23:43, Stefano Stabellini wrote: >> +Xen maintainers >> >> >> On Mon, 3 Feb 2025, Richard Henderson wrote: >>> On 2/3/25 04:54, Paolo Bonzini wrote: >>>> On 2/3/25 04:18, Richard Henderson wrote: >>>>> v1: 20250128004254.33442-1-richard.henderson@linaro.org >>>>> >>>>> For v2, immediately disable 64-on-32 TCG. >>>>> >>>>> I *suspect* that we should disable 64-on-32 for *all* accelerators. >>>>> The idea that an i686 binary on an x86_64 host may be used to spawn >>>>> an x86_64 guest via kvm is silly and a bit more than niche. >>>> >>>> At least Xen used to be commonly used with 32-bit dom0, because it saved >>>> memory and dom0 would map in guest buffers as needed. I'm not sure how >>>> common that is these days, perhaps Stefano knows. >>> >>> As a data-point, debian does not ship libxen-dev for i686. >>> We cannot build-test this configuration at all. >>> >>> I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's >>> unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for >>> an armhf host, or as an armhf binary running on an aarch64 host. >> >> >> On the Xen side, there are two different use cases: x86 32-bit and ARM >> 32-bit. >> >> For x86 32-bit, while it was a very important use case in the past, I >> believe it is far less so now. I will let the x86 maintainers comment on >> how important it is today. > > As dom0 on x86 is a PV guest per default and Linux doesn't support running as a > 32-bit PV guest since a few years now, I guess there is no need to support qemu > as 32-bit on x86 for Xen. Yet then, just to mention it, you can run a 64-bit PV Dom0 kernel underneath an otherwise 32-bit distro. I've been doing this successfully for very many years (with a very small kernel adjustment, just to work around an apparent shortcoming in system init scripts). Jan
Hi Jan, On 4/2/25 10:11, Jan Beulich wrote: > On 04.02.2025 09:19, Juergen Gross wrote: >> On 03.02.25 23:43, Stefano Stabellini wrote: >>> +Xen maintainers >>> >>> >>> On Mon, 3 Feb 2025, Richard Henderson wrote: >>>> On 2/3/25 04:54, Paolo Bonzini wrote: >>>>> On 2/3/25 04:18, Richard Henderson wrote: >>>>>> v1: 20250128004254.33442-1-richard.henderson@linaro.org >>>>>> >>>>>> For v2, immediately disable 64-on-32 TCG. >>>>>> >>>>>> I *suspect* that we should disable 64-on-32 for *all* accelerators. >>>>>> The idea that an i686 binary on an x86_64 host may be used to spawn >>>>>> an x86_64 guest via kvm is silly and a bit more than niche. >>>>> >>>>> At least Xen used to be commonly used with 32-bit dom0, because it saved >>>>> memory and dom0 would map in guest buffers as needed. I'm not sure how >>>>> common that is these days, perhaps Stefano knows. >>>> >>>> As a data-point, debian does not ship libxen-dev for i686. >>>> We cannot build-test this configuration at all. >>>> >>>> I can build-test Xen for armhf, and I guess it would use i386-softmmu; it's >>>> unclear whether x86_64-softmmu and aarch64-softmmu are relevant or useful for >>>> an armhf host, or as an armhf binary running on an aarch64 host. >>> >>> >>> On the Xen side, there are two different use cases: x86 32-bit and ARM >>> 32-bit. >>> >>> For x86 32-bit, while it was a very important use case in the past, I >>> believe it is far less so now. I will let the x86 maintainers comment on >>> how important it is today. >> >> As dom0 on x86 is a PV guest per default and Linux doesn't support running as a >> 32-bit PV guest since a few years now, I guess there is no need to support qemu >> as 32-bit on x86 for Xen. This community disconnection between QEMU and Xen communities is a bit unfortunate, as apparently we have been maintaining for some time something that isn't used. > Yet then, just to mention it, you can run a 64-bit PV Dom0 kernel underneath > an otherwise 32-bit distro. I've been doing this successfully for very many > years (with a very small kernel adjustment, just to work around an apparent > shortcoming in system init scripts). This discussion is about what is maintained by the mainstream projects. We don't want to make fork's life harder. If you believe your use case is worthwhile, please get it incorporated mainstream so we can test it. Otherwise it is too much burden to maintain things we can not even test. Regards, Phil.