On Fri, Jan 31, 2025 at 06:08:32PM +0100, Paolo Bonzini wrote: > Il ven 31 gen 2025, 17:46 Richard Henderson <richard.hender...@linaro.org> > ha scritto: > > > On 1/29/25 04:47, Paolo Bonzini wrote: > > > The difference with TCG of course is that TCG is in active development, > > and therefore its > > > 32-bit host support is not surviving passively in the same way that a > > random device is. > > > Still, I think we can identify at least three different parts that > > should be treated > > > differently: 64-on-32, 32-on-32 system-mode emulation and 32-on-32 > > user-mode emulation. > > > > Why the user/system split for 32-on-32? > > > > Various reasons which overall point at 32-on-32 system emulation being not > used very much. > > 1) 32-bit has the address space size limitation, which makes it harder to > test even moderately sized (2G) guests. > > 2) I might be wrong but user mode emulation has no equivalent of the > forced-64bit hwaddr or ram_addr_t types; 32 bit is not very 32 bit anyway > in the case of system emulation > > 3) 32-bit virtualization support only exists on x86 and possibly MIPS > > 4) system emulation is used mostly on development systems, whereas user > mode emulation might be used on small systems to run short-lived > proprietary programs > > 5) for those 32-bit hosts that have a completely separate TCG backend > (well, that's Arm), getting rid TLB accesses does eliminate a bit of code.
These days perhaps one of the more (most?) common "linux-user" scenarios I see is foreign arch containers. When telling docker/podman to run a non- native container image, it relies on qemu-user to make it all work transparently. Users probably don't even realize they're relying on QEMU, things just look a little slower. Given the prevalence of containers these days, if you have an OS install whether 32-bit or 64-bit you're probably relying on podman/docker to some extent. Those who need non-native containers is admittedly relatively niche, but it wouldn't surprise me to hear of people doing it on 32-bit machines. In general I think the biggest problem we have is that users that are likely to be impacted by our decisions won't pay any attention to QEMU upstream at all. IOW they'll never see our deprecation announcement, and thus we will never hear any feedback if they want it kept around So perhaps we need to make a bit more effort to broadcast this particular plan, given its more fundamental impact that most deprecations. I'd suggest we should put out a qemu.org blog post post asking for feedback on the proposal to drop 32-bit support. Then get people to publicise this to their distro forums/mailing lists, and/or CC lwn.net to ask for it to be featured it as a news item. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
