On 1/29/25 13:23, Peter Maydell wrote:
I'm not really strongly opposed to dropping 32-bit host support,
but I don't think a thread on qemu-devel is exactly likely to
get the attention of the people who might be using this
functionality. (You could argue that functionality without
representation among the developer community is fair game
for being dumped even if it has users, of course.)
On the other hand, broken tests that no one even runs among the
developers are not particularly significant. It's not surprising that
tests do not pass the first time and need a little tweaking when trying
them on a new platform.
There are many examples of parts of QEMU that stayed unmaintained for
years, working relatively well for limited use cases, and were only
later revamped. Most of those that I can remember are guest side: the
TCG frontend for x86, ESP emulation in hw/scsi, VGA. In fact VGA still
has a good number of emulation deficiencies and it's deprecated for
virtualization use, but no one in their right mind would suggest slating
it for removal.
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.
We could and should remove 64-on-32, maybe even without a deprecation
period, but the rest I'm not so sure. I don't know enough to understand
their maintenance cost (other than the mere existence of the 32-bit TCG
backends), but it's certainly not comparable to 64-on-32.
Paolo
